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Abstract 

An  innovative  algorithm  has  been  developed  and  evaluated  which  utilizes  Differential  GPS 
techniques  to  enhance  Link  16  navigation  and  time  synchronization  performance.  Relative 
positioning  accuracies  within  a  mobile  airborne  community  on  the  order  of  one  foot,  and  time 
synchronization  to  less  then  one  nanosecond  have  been  demonstrated.  The  algorithm  is 
structured  as  an  Extended  Kalman  Filter  mostly  these  position  errors,  clock  bias,  and  frequency 
drift.  Plans  are  described  for  laboratory  demonstration  using  Link-16  terminals  by  Spring  2004. 
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1.  Summary 


The  prime  technical  objective  of  the  work  described  in  this  report  is  to  identify,  evaluate, 
and  demonstrate  algorithms  based  upon  Link- 16  organic  navigation  capabilities  aided  by 
Differential  GPS  pseudorange  measurements  which  can  provide  enhanced  performance  in 
relative  navigation  and  time  synchronization  to  arbitrary  mobile  communities.  The  performance 
goals  of  this  technology  are  to  achieve  a  relative  positioning  accuracy,  relative  to  a  designated 
reference  platform,  of  one  meter  or  less,  a  relative  velocity  accuracy  of  0.1  ft/second  or  less,  and 
a  relative  time  base  synchronization  to  a  precision  of  one  nanosecond  or  better.  The  algorithms 
which  have  been  developed  to  satisfy  these  requirements  are  collectively  designated  as  the 
Differential  GPS  Rermement  Filter  (DGPS  RF). 

The  work  described  herein  was  initiated  under  the  Office  of  Naval  Research  (Code  ONR- 
02)  BAA  Next  Generation  Concepts,  Devices,  and  Systems  in  Navigation  and  Timekeeping 
Technologies,  under  the  technical  supervision  of  Dr.  John  S.  Kim.  This  study  was  performed 
under  defining  contract  number  C-N0014-02-C0418,  dated  October  2002,  which  included  the 
period  October  2002  through  March  2004.  Results  presented  in  this  report  cover  the  period 
October  2002  through  September  2003,  which  is  referred  to  as  Phase  1  of  this  project. 

Phase  1  is  designated  as  the  Refinement  Filter  Analysis  Study,  whose  scope  is  defined  as 
follows: 


The  contractor  (BAE  SYSTEMS,  CNIR  Division,  Wayne  NJ)  shall 
perform  analyses  of  not  less  than  two  alternative  configurations  of 
the  Refinement  Filter  (RF)  algorithm,  which  represent  alternative 
models  of  the  position  and  time  errors  resulting  from  Link-16 
nominal  navigation  performance.  The  contractor  shall  exercise  each 
of  these  configurations  on  its  simulation  software  package  under 
scenarios  designed  to  stress  the  operation  of  the  RF,  and  shall 
determine  the  parameters  of  each  version  which  provide  optimum 
system  performance.  Among  these  parameters  shall  be  the  required 
system  GPS  pseudorange  observation  rate,  covariance  rate  limiting, 
and  error  budgets  of  the  platform  inertial  navigation  units . 

The  primary  tasks  undertaken  under  Phase  1  of  the  project  included: 

-  Delivery  of  analysis  report 

-  Design  and  Code  of  Real  Time  Demonstration  RF  software 

-  Rehosting  of  Simulation  Software  on  Laptop  or  equivalent 

-  Integration  of  Full  RF  Demonstration  System. 

Phase  2  of  this  program,  commencing  in  October  2003,  is  designated  as  the  DGPS 
RF/Link-16  Demonstration.  It  covers  the  integration  of  the  DGPS  RF  Algorithm  in  real  time 
executable  code  within  a  selected  Link- 16  terminal  asset  and  demonstration  of  the  DGPS  RF 
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algorithm  performance  on  BAE  SYSTEMS’  Terminal  ATP  Test  Set.  It  will  culminate  in  a  real 
time  demonstration  of  performance  in  operationally  representative  scenarios  during  Spring  2004. 

The  intent  of  the  activity  performed  during  Phase  1  of  this  study  was  to  go  beyond  the 
specific  tasks  identified  for  this  period  by  scheduling  early  design  work  that  would  allow  a 
seamless  transition  to  Phase  2  laboratory  integration  and  demonstration.  These  “pre-Phase  2” 
tasks  included  preliminary  design  for  the  TATS  and  OCP  modifications  which  wpuld  be  required 
immediately  upon  the  start  of  the  second  phase  of  this  program.  A  brief  summary  of  the 
activities  and  results  of  the  work  performed  between  October  2002  and  September  2003  is  given 
below.  For  each  technical  area,  a  reference  to  specific  paragraphs  of  this  report  is  provided. 


Development  of  Fundamental  Algorithm  Architecture  (Paragraph  4.1) 

The  development  of  the  basic  architecture  of  the  DGPS  RF  algorithm  was  guided  by  a 
simple  idea.  We  sought  to  develop  a  design  which,  with  minimal  modifications,  could  operate 
in  any  of  the  three  environments  which  the  program  would  have  to  operate,  namely  (a)  Laptop 
or  PC  environment  (Version  1.0),  (b)  Link- 16  Terminal  /TATS  Laboratory  operation  (Version 
2.0),  or  (c)  Airborne  testing  with  real  GPS  receiver  (Versions  3.0  and  4.0).  The  central 
algorithm  routines  were  designed  to  be  essentially  common  for  all  four  versions,  while  the 
interface  routines  with  the  host  and  Link-16  OCP  were  changed  as  required  to  satisfy  specific 
requirements  of  each  operating  environment.  The  result  of  this  design  was  a  flexible  and 
responsive  algorithm  capable  of  working  in  multiple  simulation  and  operation  environments. 

Test  Bed  1  Simulation  Activities  (Paragraph  4.2) 

In  order  to  quickly  establish  the  basic  operating  performance  of  the  DGPS  RF  algorithm, 
a  simplified  test  bed,  designated  as  Test  Bed  1  was  utilized,  in  which  a  simple  trajectory 
generator  and  error  model  mimicked  Link- 16  hybrid  navigation  performance  for  the  participating 
aircraft.  Initial  runs  on  this  simulator  utilized  what  we  refer  to  as  Closed  Loop  operation,  in 
which  the  error  estimates  generated  by  the  DGPS  RF  algorithm  were  removed  from  the 
simulated  Link- 16  hybrid  navigation  solution.  DGPS  RF  state  values  were  then  zeroed.  This 
proved  to  yield  quick  convergence  to  small  error  values,  but  ultimately  resulted  in  long-term 
instability  (Figure  1-1).  When  the  DGPS  RF  error  states  were  uncoupled  from  the  Link- 16 
navigation  (Open  Loop  Operation)  stable  and  reliable  operation  meeting  all  performance  goals 
was  realized.  (Figure  1-2). 
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Figure  1-1:  Instability  in  Closed  Loop  operation 
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Figure  1-2:  Open  Loop  configuration  provides  stable  solution 


Application  ofDGPS  to  L16  Navigation 


Page  11 


Test  Bed  2  Simulation  Activities  (Paragraph  4.3) 

Test  Bed  2  was  the  designation  given  to  the  simulation  package  in  which  the  Link- 16 
navigation  model  was  represented  by  the  Link-16  Navigation  Simulator  (LNS).  This  BAE 
SYSTEMS  proprietary  software  package  represents  the  standard  for  modelling  Link-16 
navigation  performance  and  is  the  most  accurate  such  reference.  The  purpose  of  Test  Bed  2 
simulation  activity  was  to  verify  that  the  DGPS  RF  would  work  successfully  in  open  loop  mode 
with  the  LNS.  The  results  of  these  tests  were  uniformly  successful,  and  verified  that  excellent 
navigation  and  time  synch  performance  was  produced  by  the  algorithm  in  all  test  scenarios. 
(Figure  1-3). 
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Figure  1-3:  Test  Bed  2  proved  DGPS  RF  performance  with  LNS 
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DGPS  RF  Operational  Software  Design  (Paragraph  4.4) 

The  detailed  design  of  the  DGPS  RF  operational  real  time  software  is  presented  in  this  section  of 
the  report.  The  selected  architecture  divided  the  software  into  seven  basic  functions,  as  follows: 

(a)  RF_EXEC_CTRL  -  (RF  Executive  Control):  Represents  the  executive  element  in  the 
operational  software.  Controls  and  synchronizes  the  execution  of  all  subsidiary  routines 

(b)  RF_SOURCE_DATA_PROCESSE^G  -  (RF  Source  Data  Processing:  Prepares  and 
synchronizes  all  required  observation  data  for  processing  within  the  RF  Kalman  Filter 
code. 

(c)  RF_KALMAN_PROCESSING  -  (RF  Kalman  Processing):  Implements  the  five  state 
Extended  Kalman  Filter  algorithm  which  is  the  heart  of  the  algorithm 

(d)  HOST_INTERFACE_PR(X!ESSING-  (Host  Interface  Processing):  Provides  the  two 
way  interface  processing  controlling  all  data  provided  by  or  supplied  to  the  host 
computer.  This  data  is  composed  primarily  of  control  signals  and  GPS  pseudorange 
observation  data. 

(e)  OCP_INT_PROC  -  (OCP  Interface  Processing):  Provides  two  way  interface 
controlling  all  data  provided  by  or  supplied  by  the  Link- 16  Operational  Computer 
Program. 

(f)  BUILD_MASTER_MESSAGE  -  (Build  Master  Message):  Invoked  only  when  own 
platform  is  designated  as  a  master.  This  routine  constructs  the  Master  Reporting 
Message  containing  master-measured  GPS  pseudorange  observations,  as  well  as  own 
position  data,  for  transmission  via  Link- 16  to  all  other  members. 

(g)  BUILD_RF_RSLTS  -  (Build  RF  Results):  This  routine  generates  a  summary  report  to 
host  containing  all  output  data  generated  by  the  algorithm,  including  error  states, 
covariances,  and  status  variables. 
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Figure  1-4:  DGPS  RF  Software  Architecture 

The  real  time  software  architecture  described  in  this  section  is  designed  for  operation  in 
Version  1.0  (Laptop-hosted  preliminary  demonstration),  as  well  as  for  Version  2.0  (Laboratory 
demonstration  on  Link- 16  terminal  assets,  and  Version  3.0  (Airborne  flight  demonstration).  The 
simulation  results  presented  in  paragraphs  4.2  and  4.3  were  generated  using  the  code  specified  in 
this  section. 

Laboratory  Testing  Requirements  and  OCP  Design  Modifications  (Paragraph  4.5) 

The  laboratory  testing  environment  planned  for  the  Phase  2  demonstration  will  require 
significant  changes  to  both  the  Link-16  Operational  Computer  Program  (OCP),  as  well  as 
modifications  to  the  existing  Terminal  ATP  Test  Set  operational  software.  The  required 
modifications  to  the  Link-16  OCP  includes  establishment  of  a  working  interface  with  Link-16 
navigation  processing  in  order  to  provide  the  DGPS  RF  algorithm  with  the  necessary  self- 
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navigation  data.  It  will  also  be  necessary  to  provide  a  direct  interface  with  the  host  via  the  1553 
MUX  to  supply  the  real  or  simulated  GPS  pseudorange  measurements  from  all  satellites  within 
view.  Finally,  a  new  TADBL-J  message,  designated  by  J28.7,  will  be  required  to  support  the 
master  platform  reporting  of  its  measured  GPS  pseudorange  data.  With  regard  to  the  Tenmnal 
ATP  Test  Set  (TATP),  provision  must  be  made  to  supply  the  terminal  under  test  with  synthetic 
GPS  pseudorange  measurements  corresponding  to  the  satellite  ephemeris  and  the  position  of  the 
slave  platform.  Master  messages  must  also  be  transmitted  to  the  slave  platform  via  the  test 
terminal.  Finally,  new  control  and  initialization  inputs  required  to  invoke  and  control  the 
operation  of  the  DGPS  algorithm  will  also  be  required.  The  TATP  will  not  be  required  to 
generate  these  inputs;  each  of  them  will  be  precomputed  and  fed  to  the  appropriate  terminal 
input,  either  RF  or  MUX,  by  the  TATP  at  the  required  intervals  of  time. 

The  work  reported  on  within  this  section  represents  modification  of  both  the  terminal 
and  TATS  software  performed  during  Phase  1,  which  will  allow  a  seamless  and  efficient 
transition  to  laboratory  implementation  beginning  in  October  2003. 


Figure  1-5:  Real  Time  Laboratory  demonstration  configuration 


Results  and  Discussion  (Paragraph  5.0) 


The  Phase  1  effort  was  a  successful  one  in  all  respects,  with  all  goals  met  or  exceeded. 
Most  importantly,  the  intrinsic  accuracy  of  the  DGPS  RF  algorithm  was  established  under  a  wide 
range  of  potential  operating  conditions.  Only  under  extreme  navigation  errors  in  the  underlying 
Link- 16  navigation,  far  beyond  normal  operating  levels,  was  the  DGPS  RF  algorithm  made  to 
fail.  Of  equal  importance,  advance  design  work  on  required  modifications  to  both  the  Link- 16 
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operational  software  and  the  TATS  was  carried  out,  thus  paving  the  way  to  a  smooth  transition  to 
the  Phase  2  laboratory  demonstration  phase. 


Conclusion  and  Recommendations  (Paragraph  6.0) 

Two  primary  recommendations  are  set  forth  in  this  section.  The  first  is  a  proposal  for  the 
support  of  a  flight  test  of  the  DGPS  RF  algorithm  based  on  a  test  plan  implemented  for  testing  of 
BAE’s  sensor  registration  algorithm  at  Wallops  Island,  Va.  The  second  recommendation  is  that 
the  operation  of  the  DGPS  RF  be  combined  with  a  parallel  effort  for  atmospheric  refraction 
calibration  to  produce  a  robust  navigation  solution  even  in  the  event  of  GPS  jamming  for  periods 
of  time.  It  is  shown  that  these  algorithms  can  be  mutually  supporting,  with  the  DGPS  RF 
providing  accurate  locations  needed  for  RF  calibration.  Conversely,  if  GPS  is  shut  off.  Link- 16 
navigation  can  be  improved  via  the  excellent  estimation  accuracy  of  the  range  between  members 
afforded  by  the  atmospheric  filter  operation. 
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2.  Introduction 

Mission  requirements  related  to  electronic  warfare  and  precision  strike  impose 
unprecedented  requirements  on  community  relative  positioning  and  time  synchronization.  The 
achievement  of  precision  navigation  and  synchronization  among  members  of  a  mobile 
community  is  crucial  to  geolocation  algorithms  needed  to  localize  hostile  emitters.  These 
algorithms  often  utilize  combinations  of  pulse  time  difference  of  arrival  (TDOA)  and/or 
frequency  difference  of  arrival  (FDOA)  as  measured  between  participating  cooperating 
platforms.  The  need  for  precision  navigation  and  synchronization  in  support  of  geolocation 
relates  directly  to  the  need  to  perform  radar  pulse  deinterleaving  and  leading-edge  pulse 
detection.  Link-16  has  often  been  considered  as  a  potential  contributor  to  this  mission  by  way  of 
its  embedded  hybrid-inertial  navigation  capability.  The  integrity  of  Link- 16  navigation  has  been 
demonstrated  by  US  and  allied  services  in  many  thousands  of  operational  and  test  flight  hours 
since  1985.  Performance  levels  characteristic  of  organic  Link-16  navigation  are  shown  in  Figure 
2-1.  While  navigation  and  synchronization  performance  of  Link- 16  is  of  demonstrably  high 
quality,  relative  positioning  accuracy  typically  falls  within  10-30  meters,  and  thus  falls  short  of 
the  extreme  precision  desired  for  geolocation.  Similarly,  interplatform  time  synchronization  may 
fall  below  10  nanoseconds,  but  is  internal  to  the  terminal  itself  and  not  readily  available  to 
geolocation  sensors  needing  this  level  of  synchronization.  What  would  be  most  desirable  is  an 
approach  that  builds  on  Link- 16  navigation  and  time  synch  performance,  but  enhances  it  via 
additional  observation  processing.  The  development  of  such  an  algorithm  is  the  subject  of  this 
report. 
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In  a  response  to  an  Office  of  Naval  Research  (ONR)  Broad  Area  Announcement,  BAE 
SYSTEMS  proposed  a  research  study  to  investigate  the  joint  application  of  Link- 16  embedded 
navigation  and  Differential  GPS  (DGPS)  techniques  to  the  goal  of  precision  community 
navigation  and  time  synchronization.  In  May  2002,  BAE  SYSTEMS  was  selected  for  I^  2003 
and  2004  funding  to  develop  this  technology.  The  FY03  phase  of  this  study  was  dedicated 
toward  algorithm  development,  simulation,  and  documentation,  while  the  FY04  phase  is  aimed 
at  laboratory  demonstration  of  precision  navigation  and  synchronization  using  actual  Link- 16 
terminal  assets.  This  report  constitutes  the  primary  deliverable  document  for  FY03  research 
under  BAA  Solicitation  02-007. 

The  expected  payoff  of  this  study  is  the  identification  and  demonstration  of  an  algorithm, 
designated  as  the  DGPS  Refinement  Filter  (DGPS  RF)  which  is  capable  of  reducing  position 
and  timing  errors  of  a  mobile  community  to  extremely  low  levels.  The  operational  goals  of  this 
algorithm  are  (1)  relative  community  positioning  accuracy  to  a  precision  of  1  meter  or  less,  (2) 
relative  velocity  accuracy  of  better  than  0.1  ft/second,  and  (3)  common  time  synchronization  to  a 
level  of  one  nanosecond  or  better.  Because  this  approach  requires  no  modification  to  the 
government’s  Link- 16  terminal  assets  beyond  the  addition  of  certain  software  algorithms,  it 
provides  an  economical  growth  path  to  reaching  the  stated  performance  goals. 

Link- 16  utilization  of  GPS  data  for  navigation  updates  and  synchronization  has  been  a 
fact  for  many  years.  The  use  of  the  one  PPS  time  discrete  as  a  measurement  of  UTC  time  results 
in  Link- 16  network  time  synchronization  to  that  standard.  In  the  case  of  navigation  data,  GPS 
PVT  (position,  velocity,  and  time)  measurements  are  processed  by  any  Link- 16  terminal  as  a 
direct  observable  for  platform  position,  and  thus  contribute  to  the  accuracy  of  the  navigation 
solution.  The  navigation  accuracy  illustrated  in  Figure  2-1  is  indicative  of  the  results  of  this  GPS 
position  aiding.  Our  approach  for  the  DGPS  RF  is  not  to  ignore  this  very  accurate  navigation 
solution,  but  to  utilize  it  as  a  foundation,  which  can  then  be  further  refined  by  processing 
additional  measurements.  What  are  these  additional  measurements?  We  have  decided  to  utilize 
the  raw  pseudorange  measurements  available  from  all  visible  GPS  satellites  as  the  source  of  new 
observations,  which  the  DGPS  RF  requires  to  refine  residual  position  and  time  errors  remaining 
from  the  existing  Link- 16  navigation  solution. 

We  will  be  seeking  a  relative  solution,  in  which  all  mobile  members  estimate  their 
position  and  time  errors  with  respect  to  a  selected  community  member,  designated  as  a  Master 
Platform.  Any  platform,  static  or  mobile  may  be  so  designated.  All  remaining  members  are 
thus  “slaves”,  who  seek  to  determine  their  position  and  timing  errors  relative  to  the  master. 
Should  the  master  be  accurately  located  in  absolute,  i.e.  WGS-84  coordinates;  this  relative 
correlation  automatically  will  converge  to  an  absolute  one  in  the  WGS-84  frame  of  reference. 

The  task  of  the  DGPS  RF,  which  is  implemented  on  each  platform,  is  thus  to  estimate  the  five- 
element  error  vector  which  is  the  residual  error  of  the  Link- 16  navigation.  The  constituents  of 
this  error  vector  are  three  components  of  relative  position  error,  a  relative  clock  bias  and  relative 
frequency  between  each  platform  and  the  master.  As  will  be  derived  in  paragraph  3.0,  the 
configuration  of  the  DGPS  RF  is  that  of  an  Extended  Kalman  Filter  (EKFl  which  models  the  five 
error  components  described  above.  The  question  remains  as  to  how  the  GPS  pseudorange 
information  should  be  presented  to  the  DGPS  RF  for  processing.  We  have  selected  a  differential 
mode,  that  is,  a  vector  of  pseudorange  differences  as  measured  between  the  master  and  all  slaves. 
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The  logic  for  this  choice  is  as  follows.  GPS  pseudorange  errors  are  directly  affected  by  both 
tropospheric  and  ionospheric  propagation  delays,  which  basic  GPS  processing  algorithms 
attempt  to  compensate  for.  Differential  operation  can  reduce  these  errors  to  small  values  by 
taking  advantage  of  the  high  spatial  correlation  of  these  terms  within  100-200  Km  on  the  earth’s 
surface.  This  is  the  basis  of  conventional  DGPS  operation,  which  usually  involves  the  placing  of 
a  GPS  receiver  at  a  known  (well-surveyed)  position  on  the  earth,  and  comparing  received 
pseudorange  with  values  compatible  with  known  satellite  ephemeris.  Here,  we  have  no  such 
surveyed  position.  The  steady  state  error  behavior  of  Link- 16  is  well  known  from  both 
simulation  and  flight  testing,  and  may  be  characterized  by  a  Markov  process  with  correlation 
time  measured  in  hundreds  of  seconds,  that  is,  it  is  basically  a  slowly  varying  quantity.  If  we  can 
provide  measurements  with  time  constants  at  least  an  order  of  magnitude  less  than  this,  we  can 
eliminate  the  need  for  a  static  and  surveyed  reference  point.  This  is  the  fundamental  principle  on 
which  the  DGPS  RF  relies.  The  measurements  we  use  are  those  of  the  differential  satellite 
pseudoranges  (PR)  themselves  (that  is,  master  minus  slave  measurements  of  each  satellite  PR) 

This  project  represents  an  effort  extending  over  FY03  and  FY04  to  develop  the  DGPS  RF 
technology  with  a  goal  of  demonstrating  its  performance  within  an  actual  Link- 16  terminal  in  a 
laboratory  environment  by  2Q  FY04.  It  has  always  been  the  intention  of  BAE  SYSTEMS  that 
the  DGPS  RF  operational  software  used  within  this  laboratory  demonstration  be  configured  as 
closely  as  possible  to  flight  ready  and  operational  software.  This  would  pave  the  way  toward 
early  flight  testing  and  possible  operational  use.  For  this  reason,  the  scope  of  the  FY03  project 
effort  extends  beyond  the  analysis  and  proof  of  performance  of  the  DGPS  RF  algorithm  to 
include  rigorous  design  and  documentation  of  a  near-operational  code  version.  In  addition,  the 
inclusion  of  new  (to  Link- 16)  observations  and  interfaces  require  specification  of  code  changes 
needed  to  current  Link- 16  software  and  terminal  test  equipment. 

During  this  project,  the  analysis  and  development  of  the  DGPS  algorithm  initially  utilized 
simple  community  navigation  error  models,  and  then  tested  its  performance  within  a  rigorous 
representation  of  Link- 16  navigation  code  known  as  the  Link- 16  Navigation  Simulator. 

Extensive  trials  were  performed  to  optimize  algorithm  performance  by  varying  certain 
parameters,  such  as  state  configuration,  tuning  constants,  update  rates,  initial  navigation  errors 
and  community  configurations.  The  end  result  was  an  extremely  robust  and  flexible  algorithm 
that  provides  excellent  position  and  time  error  recovery  equaling  or  bettering  our  initial 
performance  goals.  Detailed  analysis  and  results  of  each  of  the  candidate  algorithm 
configurations  is  included  within  this  report. 

The  design  and  specification  of  the  final  derived  algorithm  had  to  take  into  consideration 
the  fact  that  several  different  versions  of  the  software  are  required.  Version  1.0  is  designed  for 
early  demonstration  on  a  PC  or  laptop  environment  using  simulated  satellite  data  based  upon  a 
circular  orbital  configuration.  It  dso  interfaces  with  the  Link-16  Navigation  Simulator.  This 
version  will  be  utilized  for  the  interim  demonstration  scheduled  for  September  2003.  Version 
2.0  constitutes  the  laboratory  version,  designed  for  integration  within  the  Link- 16  operational 
software.  This  version  utilizes  a  full  elliptical  satellite  model  and  mimics  GPS  input  data 
characteristic  of  a  Canadian  Marconi  GPS  satellite  receiver.  Version  3.0  is  reserved  for  flight- 
ready  software  capable  of  using  arbitrary  GPS  receiver  units.  The  core  processing  routines  of 
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each  of  these  versions  are  nearly  identical,  and  differ  only  in  the  interface  processing  routines 
dealing  with  the  navigation  software  and  host  interface. 

Since  the  laboratory  demonstration  of  the  DGPS  RF  must  operate  within  a  Link- 16 
terminal,  certain  unavoidable  changes  are  required  to  the  current  operational  terminal  software  to 
allow  the  integration  with  the  new  algorithm.  For  technical  reasons  relating  to  solution  stability, 
no  direct  feedback  of  the  results  of  the  DGPS  RF  solution  may  be  allowed  to  affect  the  current 
LINK-16  navigation  algorithm.  Nonetheless,  many  changes  to  the  existing  Link-16  software  are 
required  to  accept  the  satellite  pseudorange  measurements  and  to  output  results  of  the  new 
configuration.  In  addition,  a  new  Link- 16  message,  designated  as  the  Master  Message,  is 
required  to  convey  pseudoranges  measured  at  the  master  platform  to  all  other  units.  Although 
detailed  coding  of  these  required  changes  will  not  commence  until  FY04,  the  design  of  these 
software  modifications  was  initiated  within  the  scope  of  the  FY03  activity  and  reported  on  in  this 
report. 

The  requirement  for  laboratory  testing  also  imposes  new  and  different  requirements  on 
the  laboratory  test  set  (Terminal  ATP  Set  —  TATS)  on  which  the  recoded  terminal  will  be 
exercised.  The  task  of  the  TATS  is  to  replicate  at  both  the  RF  and  host  terminal  interfaces 
exactly  the  type  and  format  of  data  required  by  the  DGPS  RF  algorithm.  None  of  these  data 
types  is  currently  implemented  in  Link- 16  test  equipment.  One  example  of  this  data  is  the  need 
to  replicate  the  simulated  pseudorange  data  in  a  format  characteristic  of  a  modem  GPS  receiver. 
Another  example  is  the  generation  of  Master  Messages  containing  precisely  regulated 
pseudorange  data  coming  from  the  simulated  master  platform.  Still  another  example  is  the  need 
to  accept  new  precision  navigation  results  from  the  DGPS  RF  for  data  recording  and  analysis  to 
prove  its  performance  within  the  terminal  environment. 

The  activity  summarized  above  constitutes  the  scope  of  work  performed  during  the  FY03 
period,  and  is  reflected  in  the  structure  of  the  remainder  of  this  document,  as  follows: 


Paragraph  3.0  -  Development  of  Fundamental  Equations 

This  section  contains  the  derivation  of  the  fundamental  mathematical  relationships  of  the 
DGPS  RF,  including  the  specification  of  the  related  Kalman  Filter  modeling  expressions  on 
which  it  depends.  This  section  also  describes  two  alternative  methods  of  specifying  the  GPS 
satellite  motion  (circular  and  elliptical)  which  are  required  for  both  simulation  and  terminal 
implementation  of  the  DGPS  RF  algorithm. 


Paragraph  4.0  -  Methods  and  Procedures 

This  section  presents  a  detailed  description  of  the  development  methodology  of  the 
DGPS  RF  algorithm,  a  narrative  of  significant  development  and  simulation  studies  performed 
and  a  full  analysis  of  results.  It  also  includes  comprehensive  software  design  specifications  of 
the  developed  RF  algorithm  and  implementation  plans  for  FY04  on  both  Link- 16  operational 


Application  ofDGPS  to  LI6  Navigation 


Page  21 


software  and  changes  required  for  the  laboratory  test  equipment.  The  contents  of  this  section 
shall  be  as  follows: 

4. 1  Development  Plan  for  Simulation,  Laboratory,  and  Flight  Test  Versions  of  the 
DGPS  RF  software 

4.2  Algorithm  Development,  Test,  and  Analysis 

4.3  Software  Design  for  DGPS  RF  Algorithm 

4.3.1  Test  Bed  1  Covariance  Based  Navigation  Model 

4.3.2  Test  Bed  2  LNS  Navigation  Model 

4.3.3  Algorithm  Simulation  Study  Sununary  and  Conclusion 

4.4  DGPS  RF  Operational  Software  Design 

4.5  Laboratory  Testing  Requirements  for  DGPS  RF  Algorithm  -  TATS  and  OCP 
Design  Modifications 


Paragraph  5.0  -  Results  and  Discussion 
Paragraph  6.0  -  Recommendations 

Recommendations  for  further  algorithm  development  and  demonstration. 


Paragraph  7.0  -  Conclusions 

Summary  of  significant  project  results  for  FY03 


Paragraph  8.0  References 
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3.  Development  of  Fundamental  Equations 

3.1  DGPS  as  a  Correction  to  Link-16  Navigation  Solutions 

The  extremely  precise  level  of  accuracies  we  are  seeking  immediately  suggests  the 
application  of  differential  GPS  measurements  on  pseudorange  data  provided  by  the  GPS  satellite 
constellation.  Differential  positioning  accuracy  of  two  members  with  conventional  timing  on  the 
C/A  or  P(Y)  code  heretofore  has  required  the  establishment  of  a  surveyed  reference  point, 
which  can  provide  “truth”  measurements  of  pseudorange  to  the  satellites.  Using  the  truth 
estimates,  tropospheric  and  ionospheric  refraction  corrections  can  be  derived,  which  are  then 
data-linked  to  mobile  members  to  reduce  the  effect  of  these  terms\  Since  the  warfighter  mission 
of  emitter  location  may  take  place  over  territory,  which  has  no  such  surveyed  reference  point 
available,  it  may  appear  at  first  glance  that  DGPS  techniques  cannot  be  applied  to  our  problem. 

In  fact,  DGPS  measurements  cm  be  successfully  processed  without  a  surveyed  reference  point  if 
an  alternative  reference  not  dependent  on  such  a  static  point  can  be  found. 

Let  us  take  a  step  back  from  the  problem  to  consider  the  following  considerations.  We 
are  essentially  seeking  a  relative  solution  between  a  designated  master  and  another  slave 
platform.  That  is  to  say,  we  wish  to  accurately  estimate  their  position  differences  in  some 
convenient  frame  of  reference,  not  necessarily  WGS-84.  We  note  that  Link-16  navigation, 
particularly  when  GPS  aided,  already  provides  such  a  solution,  although  not  to  the  required 
aecuracy.  This  solution  enables  us  to  compute  a  (time- varying)  baseline  between  any  two 
mobile  platforms.  Furthermore,  even  though  the  length  and  orientation  of  the  moving  baseline 
may  change  extremely  rapidly  for  fast  moving  aircraft,  the  errors  or  perturbations  in  this 
solution  do  not,  particularly  if  the  platforms  are  equipped  with  well  calibrated  inertial  navigation 
systems  (INS).  More  specifically.  Link- 16  navigation  integrates  inertial  navigation 
measurements  within  a  hybrid-inertial  mechanization  whose  characteristic  errors  are 
represented  within  Figure  2-1 .  These  errors  are  slowly  varying  with  time  constants  measured  in 
tens  or  hundreds  of  seconds.  Let  these  errors  be  represented  by  ex,  ey,  and  ez  in  some  local  level 
reference  frame.  An  algorithm,  to  be  deseribed  in  the  next  paragraph,  will  provide  accurate  and 
rapid  measurements  of  these  errors  within  a  period  that  is  short  compared  to  their  time  constants, 
and  reduce  them  to  small  values 


3.2  Derivation  of  DGPS  RF  State  and  Measurement  Equations 

The  potential  measurements  at  our  disposal  for  this  problem  are  (a)  PPLI  messages 
provided  by  the  Link- 16  system,  and  (b)  GPS  pseudorange  measurements  provided  by  a  military- 
quality  GPS  receiver  (Please  note  that  GPS  PVT  measurements  are  assumed  to  be  already 
processed  by  Link-16  as  part  of  its  normal  hybrid  navigation  function).  Figure  3.2-1  represents 
the  relative  positions  of  a  designated  master  platform  (A)  and  a  slave  platform  (B).  We  consider 
the  measured  pseudoranges.  Si  from  a  given  GPS  satellite  i,  where  i  ranges  from  1  to  NV  (NV  is 
equal  to  the  number  of  visible  satellites  common  to  both  platform  A  and  platform  B).  The 
measured  pseudorange  to  A  is  designated  by  Sj/A,  and  that  to  B  by  Si/B.  We  select  as  a 
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representative  frame  of  reference  the  Local  Level  Coordinate  System  (X,  Y,  Z)  centered  at  the 
master  platform  and  moving  with  it.  This  is  an  orthogonal  reference  frame  with  X  pointing  true 
North  from  the  master,  Y  true  West,  and  Z  Up. 

The  choice  of  pseudorange  differences  as  a  potential  observation  rather  than  the 
pseudoranges  themselves  is  a  straightforward  one.  The  time  delays  attendant  with  S  JA  and  Si/B 
,  both  ionospheric  and  atmospheric,  can  be  assumed  to  be  nearly  equal  due  to  the  fact  that  the 
range  between  A  and  B  is  small  compared  to  the  distances  to  the  GPS  satellites  themselves 
(approximately  1 1000  NM).  By  differencing  pseudoranges  from  all  visible  satellites,  the 
common  time  delays  drop  out  of  the  range  equation  and  may  be  safely  ignored.  A  second  choice 
in  the  use  of  the  pseudorange  differences  is  the  use  of  either  (a)  P(Y)  code  phase  measurements 
or  (b)  carrier  phase  measurements,  both  of  which  are  usually  available  from  military  GPS 
receivers.  Use  of  the  carrier  phase  measurements,  as  is  often  done  in  precision  DGPS 
measurements  using  surveyed  reference  points  can  provide  centimeter  accuracy  on  positioning, 
but  results  in  a  modulo  In  phase  ambiguity  in  carrier  measurement  since  relative  positioning 
errors  may  add  up  to  many  carrier  wavelengths.  There  are  various  methods  available  for 
estimation  of  the  integer  wavelength  differentials,  but  most  of  these  require  extended  processing 
time^  which  may  exceed  the  position  error  time  constants  of  our  navigation  solution.  We  were 
unable  to  find  any  references  in  the  technical  literature  for  methods  of  phase  ambiguity 
resolution  fast  enough  for  our  purposes.  We  therefore  decided  to  proceed  using  code  phase 
measurements  instead,  anticipating  that  processing  of  enough  data  would  compensate  for  the 
coarser  resolution  of  the  pseudorange  measurement  data  as  compared  with  carrier  phase 
operation.  Simulation  results  presented  later  in  this  report  seem  to  bear  out  this  assumption. 
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In  Figure  3.2-1,  above,  the  pseudorange  difference  quantity  Si  /A  -  Si  /B  is  expressed  in  Equation 
(1)  as: 

5PR  =  8  Pseudorange  A/B  =  8x  Cxsi  +  5y  Cysi  +  5z  Czsi  +  Be  *  Cs  (1) 

where  8x  =  Absolute  *  difference  between  A  &  B 

=  Axn  + 

nominal  difference 
based  upon  navigation 
solution 

8y  =  Absolute  y  difference  between  A  &  B 
=  AyN+ey 

8z  =  Absolute  z  difference 

CxSi,  Cysi,  CzSi  =  direction  cosines  between  Si/A  and  X,  Y,  Z  axes 

Be  =  Clock  Bias  between  A  &  B 

Cs  =  Speed  of  light  (ft/ns)  =  0.983569  ft/ns 


Based  upon  the  definition  of  terms  in  Equation  1,  we  note  that  potential  variables  of  interest, 
which  could  be  estimated  via  the  DGPS  RF,  are: 

-  Three  elements  of  relative  position  error(  £x,  £y,  £z) 

-  Three  time  derivatives  of  the  relative  position  errors  (£x,  £y,  £z) 

-  Clock  Bias  (Be) 

-  Derivative  of  Clock  Bias  or  frequency  drift  between  platforms  (fc) 

The  presence  of  a  Clock  Bias  term  in  Equation  (1)  indicates  that  the  measurement 
differential  is  expressed  in  terms  of  both  time  and  position  errors.  These  error  terms  are 
separable  only  on  the  basis  of  a  common  estimation  process,  and  cannot  be  treated 
independently.  Furthermore,  the  Clock  Bias  term  in  Equation  (1)  represents  the  time  difference 
reflected  in  the  GPS  time  base,  rather  than  the  similar  term  reflecting  the  difference  between  the 
Link-16  terminal  time  bases.  Timing  errors  within  the  GPS  time  base  will  vary  depending  on  the 
number  of  satellites  processed  and  the  quality  of  the  navigation  solution.  A  typical  value  of  the 
steady  state  relative  time  differences  within  the  GPS  time  base  might  be  as  high  as  10-15 
nanoseconds,  a  significant  term  compared  to  the  accuracies  that  we  are  seeking.  Furthermore, 
there  might  still  remain  a  level  of  oscillator  drift,  resulting  in  a  time  derivative  term  of  the 
relative  clock  bias.  Be. 
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Based  upon  the  above  considerations,  the  Extended  Kalman  Filter  (EKF)  formulation  of 
the  DGPS  RF  state  vector,  X,  could  be  as  large  as  8  elements,  defined  as: 

If  velocity,  error  terms  are  modeled  as  constant. 

xi  =e\ 

X2  =ex 
X3=£y 
X4=£y 

X5  =ez 
X6  -sz 

X7  =Bc 

xg  =  fc  (Relative  Bias  Between  A,  B  GPS  Sets) 

(Relative  Frequency  Drift  between  A,  B  GPS  Sets)  (2a) 

Time  Propagation  of  these  terms  is  thus  - 

Xi=X2  X5=X6 
X2=0  ^=0 

X3=^  X7^ 

^=0  %=0  (2b) 

The  relative  range  between  master  and  slave,  5r,  may  be  expressed  in  terms  of  the  variables 
defined  above: 

^  R  =  [(Axn  +  +  (AyN  +  £y)^  +  (Azn  +  ez)^ 

=  [(Axjvi^  +  2Axn  •  £X)  +  (Ayfsi^  +  2AyN  •  ej)  +  (Az^^  +  2Azn  •  £Z)]^^^  (3) 

if  square  terms  in  en,  £y,  €z  are  neglected 


Two  potential  observation  t)q)es  for  the  DGPS  RF  are  considered,  namely: 

yl  =  Range  between  Master  and  Slave  -  Provided  by  Link  16  PPLI 

Message  (Note  that  there  will  be  one  measurement  per  PPLI  message  where 
NC  is  the  number  of  suitable  satellites  commonly  visible  to  both  master  and 
slave  platforms) 

y2  =  Pseudorange  Differences  to  each  satellite  from  master  and  slave. 

(Note  that  there  will  be  NV  such  measurements  at  each  update) 

Based  on  Equations  (1-3),  the  derivation  of  the  observation  partial  derivatives  for  each  of  these 
observation  types  is  a  straightforward  exercise.  The  results  are: 
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H(l,l)  = 
H(l,3)  = 
H(l,5)  = 


dSR 

Axn 

dex 

SR 

dSR 

AyN 

dey 

^R 

dSR 

Azn 

dsz 

<5R 

Range  Observation  Derivatives 


ddPR  ^ 
a^PR 
a^pR 
a5PR  ^ 

j  =  2,NV+l 

i=j  1 


J 


PseudoRang  DifferenceDerivativs 


(4) 


Where  8R  is  the  nominal  range  between  members  A,  B  =  (Axn^  +  AyN^  +  Azn^)'^^ 

[  H  ]  is  the  Kalman  Filter  Observation  Matrix 
(NV+l)x8 

The  direction  cosine  terms  in  the  above  equation  shall  be  generated  as  functions  of  member 
platform  positions  and  the  ECEF  positions  of  the  satellites,  as  computed  via  satellite  ephemeris 
data.  Details  are  presented  in  paragraphs  3.3.  The  observation  matrix,  H,  will  be  required  for  the 
construction  of  the  DGPS  RF  Kalman  Filter  algorithm,  as  detailed  in  paragraph  3.4. 


3.3  Prediction  of  Satellite  Pseudorange  Measurements 

The  use  of  GPS  pseudorange  data  for  the  DGPS  RF  Kalman  Filter  requires  representative 
models  of  the  satellite  constellation  orbital  mechanics.  The  fiilly  operational  GPS  constellation 
includes  24  or  more  (28  as  of  March  2000)  satellites  approximately  uniformly  dispersed  around 
six  (nearly)  circular  orbits  each  with  four  or  more  satellites.  The  orbits  are  inclined  at 
approximately  55  degrees  relative  to  the  equator,  and  are  separated  from  each  other  by  multiples 
of  60  degrees  right  ascension.  The  orbits  are  nongeostationary  and  approximately  circular,  with 
radius  of  26,560  Km,  and  orbital  periods  of  one-half  sidereal  day  (approximately  1 1.967  hours). 

For  purposes  of  DGPS  algorithm  development  and  simulation,  modeling  of  the  satellite 
mechanics  utilized  a  simple  circular  orbit  model,  since  this  is  an  excellent  representation  of  the 
actual  GPS  satellite  orbital  dynamics.  This  modeling  was  utilized  for  Version  1 .0  of  the 
developmental  software  simulation  and  testing.  The  operational  use  of  GPS  satellite 
pseudorange  data,  however,  requires  the  implementation  of  the  true  elliptical  satellite  model  and 
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solving  the  nonlinear  Kepler  equation  using  ephemeris  data  for  each  of  the  participating 
satellites.  All  laboratory  and  flight  test  versions  of  the  DGPS  RF  software  will  use  the  elliptical 
satellite  orbital  models.  Both  circular  and  elliptical  satellite  models  have  a  single  purpose  -  that 
of  predicting  to  high  accuracy  the  coordinates  of  each  satellite  within  the  Earth  Centered,  Earth 
Fixed  (ECEF)  coordinate  frame  at  specified  times. 

The  mechanization  of  the  DGPS  algorithm  involves  two  coordinate  frames  of  reference, 
namely:  (a)  ECEF,  and  (b)  Local  Level  -  North,  West,  Up,  as  well  as  the  ability  to  transform 
specific  vector  quantities  between  them.  ECEF  coordinates,  by  definition,  have  their  origin  at 
the  earth’s  center.  The  ECEF  X-axis  lies  in  the  equatorial  plane  and  passes  through  the  prime 
meridian  at  Greenwich.  The  Z  axis  passes  through  the  north  pole,  while  the  Y-axis  is  orthogonal 
to  X  and  Z  such  that  XYZ  represents  a  right  hand  system.  The  Local  Level  frame  of  reference 
used  will  have  axes  parallel  to  local  North/WestAJp  directions  specified  at  a  the  master’s 
position.  The  transformation  between  these  coordinate  systems  is  an  orthogonal  one,  and  is 
represented  by  matrix  [Ttf]  such  that  (Equation  5): 


Ltle  J  Ivecef  J=  LVix  J 


(5) 


where  :  [Tle  ]  is  an  orthogoanl  transform  ation  matrix  given  by  : 

-  sin  X  cos  ^  -  sin  I  sin  (p  cos  X 
[tle]  =  sin  (p  cos  (p  0.0 

cos  X  cos  (p  cos  X  sin  (p  sin  X 

X  =  Platform  latitude 

(p  =  Platform  longitude 

Vecef  =  Vector  in  ECEF  Coordinate  s 

Vll  =  Vector  in  Local  Level  Coordinate  s 


3.3.1  Circular  Satellite  Dynamic  Model 

A  simple  circular  orbit  model  is  useful  for  approximating  the  elliptical  orbit  of  an  actual 
GPS  satellite  constellation  The  ECEF  positions  of  each  of  the  satellites  when  the  circular 
model  is  used  may  be  specified  in  terms  of  five  parameters,  namely: 

-  Right  Ascension  Angle  (Q) 

-  Orbital  Position  ( v) 

-  Orbital  Inclination  (a) 

-  Nominal  Orbital  Radius  (Rr)  =  87,051,108  feet 

-  Time  in  Seconds  from  Epoch 
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The  parameter  Q.  represents  the  longitude  where  the  orbital  plane  intersects  the  earth 
equatorial  plane  as  the  satellite  crosses  from  the  Southern  Hemisphere  to  the  Northern 
Hemisphere.  The  orbital  inclination  for  all  GPS  satellites  is  approximatly  55  degrees.  For  GPS 
satellite  orbits,  the  angle  v  changes  at  a  nearly  constant  rate  of  about  1 .4584  x  10  -  4 
radians/second,  and  a  period  of  about  43,082  seconds  (half  a  day) . 

The  nominal  satellite  position  of  any  given  satellite  in  ECEF  coordinates  is  then  given  as 
(Equation  6): 


ECEFXS  =  Rk  [cos  v  cos  Q  -  sin  v  sin  Q  cos  a] 
ECEFYS  =  Rk  [cos  v  cos  Q  +  sin  v  sin  Q  cos  a] 
ECEFZS  =  Rk  [sin  v  sin  a] 


(6) 
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V  =  Vo  (specified  for  each  satellite)  +  (t  -to)  360/43,082  degrees 
Q  =  Qo  (specified  for  each  satellite)  -  (t  -to)  360/43,082  degrees 
Rk  =  Nominal  Satellite  Radians  (ft)  =  87,051,108  ft 

Note:  Although  actual  satellite  ephemeris  data  is  expressed  in  terms  of  meters,  the 
DGPS  RF  state  elements  will  be  expressed  in  English  units  (ft).  Thus, 
conversion  of  satellite  ECEF  coordinates  must  be  converted  to  English  units 

3.3.2  Elliptical  GPS  Satellite  Model 

The  corresponding  computation  of  satellite  ECEF  positions  for  actual  GPS  satellites  in 
elliptical  orbits  is  a  good  deal  more  complex  than  the  circular  model.  This  solution  requires  the 
solution  of  Kepler’s  equation  and  the  availability  of  satellite  ephemeris  data  for  each  satellite. 
The  detailed  algorithm  for  this  process  is  well  known  (See,  for  example,  reference^),  and  is 
implemented  in  all  operational  GPS  receivers. 

GPS  satellite  ephemeris  data  for  all  GPS  satellites  is  transmitted  by  the  constellation 
within  the  50  bps  data  stream.  Each  satellite  will  transmit  current  ephemeris  data  not  only  for 
itself,  but  for  all  other  satellites  within  the  constellation.  This  data  can  be  represented  by  a  28  x 
23  matrix  EPHEM  (k,  23),  where  k  represents  the  individual  satellite  ID.  Within  the  Canadian 
Marconi  NORTHSTAR  unit,  a  representative  GPS  receiver,  the  received  ephemeris  data  is 
outputted  at  selected  intervals  of  time  within  a  specific  message,  denoted  as  Message  22.  The 
detailed  format  of  this  interface  is  presented  in  Reference**. 

The  contents  of  the  Ephemeris  Matrix  shall  be  as  presented  in  Table  3.3-1.  The 
processing  algorithm  utilized  for  the  generation  of  the  Satellite  ECEF  coordinates  is  given  in 
Figure  3.3-1  and  Figure  3.3-2. 
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VAR 

EMPEM  ARRAY  ID 

DESCRIPTION 

SVNO 

=  EPHEM(K,1) 

Satellite  vehicle  number 

WEEKNO 

=  EPHEM(K,  2) 

Week  No. 

TGD 

=  EPHEM(K,3) 

Time  of  Week 

TOC 

=  EPHEM(K,4) 

Ephemeris  Reference  Time 

AF2 

=  EPHEM{K,  5) 

2nd  Clock  Correction  Coefficient 

AFl 

=  EPHEM(K,  6) 

1®^  Order  Clock  Correction  Coefficient 

AFO 

=  EPHEM{K,7) 

Qth  Order  Clock  Correction  Coefficient 

CRS 

=  EPHEM(K,8) 

Amplitude  of  sine  harmonic  correction  term  to 
orbit  radius  [m] 

DELN 

=  EPHEM(K,9) 

mean  motion  difference  [semicircle/s] 

MO 

=  EPHEM(K,  10) 

Mean  anomaly  at  reference  time  [smeir] 

cue 

=  EPHEM{K,  11) 

Amplitude  of  cos  harmonic  correction  term  to 
the  arqument  of  latitude  [rad] 

ES 

=  EPHEM(K,  12) 

Eccentricity 

CUS 

=  EPHEM(K,13) 

Amplitude  of  sine  harmonic  correction  term  to 
the  argument  of  latitude  [rad] 

SAS 

=  EPHEM(K, 14) 

Square  root  of  semi -major  axis  [m"^l/2] 

TOE 

=  EPHEM(K,  15) 

Ephemeris  reference  time  (from  Epoch) 

CIC 

=  EPHEM{K,16) 

Amplitude  of  cos  harmonic  correction  term  to 
the  angle  of  inclination  [rad] 

OMEGAO 

=  EPHEM(K,17) 

Longitude  of  ascending  node  of  orbit  plane  at 
weekly  epoch 

CIS 

=  EPHEM(K,18) 

Amplitude  of  sine  harmonic  correction  term  to 
the  angle  of  inclination  [rad] 

IOTA 

=  EPHEM{K,  19) 

Inclination  angle  at  reference  time 
[semicircle] 

CRC 

=  EPHEM{K,20) 

Amplitude  of  cos  harmonic  correction  term  to 
the  orbit  radius  [m] 

W 

=  EPHEM(K,21) 

Argument  of  perigee  [semicircle] 

OMEGAD 

=  EPHEM(K,22) 

Rate  of  right  ascension  [semicircle/s] 

I  DOT 

=  EPHEM(K,23) 

Rate  of  inclination  angle  [semicir/s] 

Table  3.3-1:  Ephemeris  Message  22  Elements 
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MU  =  3.986008  E14  [m*3/s^2] 

OMEGAE  =  7.292115167  E-5  [rad/s] 

TK  =  PGPST  -  TOE 
IF  (TK  >  302400.0)  THEN 

PGPST  =  PGPST  -  604800.0 
IF  (PGPST  <  302400.0)  THEN 

PGPST  =  PGPST  +  604800.0 

IAS  =  SAS*2 
NO  =  SQRT(MU/AS*3) 

N  =  NO  +  DELN 
MK  =  MO  +  N*TK 

EKNEW  =  MK 
FOR  JX: 1:100  DO 

EKOLD  =  EKNEW 
EKNEW  =  MK  +  ES*SIN (EKOLD) 

END 

EK  =  EKNEW 

FK  =  ACOS ( (COS (E) -1) / (l-ES*COS(E) ) ) 
PHI  =  FK  +  W 

DELR  =  CRC*COS(2*PHI)  +  CRS*SIN 
DELI  =  CIC*COS (2*PHI)  +  CIS*SIN 
DELM  =  CUC*COS (2*PHI)  +  CUS*SIN 

RK  =  AS(1  -  ES*COS(EK))  +  DELR 
MU  =  PHI  +  DELM 
lOTAK  =  IOTA  +  DELI  +  IDOT*TK 

OMEGAK  =  OMEGAO  +  OMEGAD* (TK  -  TOE)  - 
OMEGAE* TOE 

XKl  =  RK*COS(MU) 

YKl  =  RK*SIN(MU) 


Earth' s  imi  gravitational  param 
Earth's  rotation  rate 

Time  from  epoch 


Semi -major  axis 
Computed  mean  motion 
Corrected  mean  motion 
Mean  anomaly 

Newton-Raphson  estimation 

Kepler's  EQ  for  eccentric 
anomaly 

★  ★  * 

Argument  of  latitude 

Radius  correction 
Correction  to  inclination 
Argument  of  latitude  correction 

Corrected  radius 

Corrected  argument  of  latitude 

Corrected  inclination 

Corrected  longitude  of 
ascending  node 

Position  in  orbital  plane 


(2*PHI) 

(2*PHI) 

(2*PHI) 


XK  =  XKl*  COS  (OMEGAK)  -  YKl  *  COS  ( lOTAK)  *  SIN  (OMEGAK) 

YK  =  XKl* SIN (OMEGAK)  +  YKl * COS ( I OTAK) * COS (OMEGAK) 

ZK  =  YKl*SIN(IOTAK) 

PR  =  SQRT(  (XS-XP)  ^2  +  (YS-YP)  ^2  +  (ZS-ZP)''2) 

PRSEC  =  PR/C  Pseudorange  in  seconds 

IPGPS  =  PGPST  Integer  value  of  PGSTM 

FPGPS  =  PGPST  -  FLOAT (IPGPS)  Fractional  GPS 


CDPHASE  =  (FPGPS  -  PRSEC)  *CR _ Codephase  derivation _ \ 

Figure  3.3-1:  Code  Phase  Derivation  from  Ephemeris  Message  22 
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For  K  =  1,  24 
Compute  mean  motion 

DELN  :=  EPHEM(INVERS{ISVNO)  ,9) 

SAS  =  EPHEMdNVERS  (ISVNO)  ,  14) 

AS  =  SAS^2 

N  =  DSQRT(MU/AS^3)  +  DELN 

Compute  mean  anomaly 

MO  =  EPHEMdNVERS  (ISVNO)  ,  10) 

MK  =  MO  +  N* (TC  -  TOE) 

Solve  for  eccentric  anomaly 

ES  =  EPHEMdNVERS  (ISVNO)  ,12) 

EKNEW  =  MK 

FOR  JX: 1:100  DO 

EKOLD  =  EKNEW 

EKNEW  =  MK  +  ES*SIN (EKOLD) 

END 

E  =  EKNEW 

Compute  time  correction  term 
DEKTR  =  F*ES*SAS*SIN(E) 

AFO  =  EPHEMdNVERS  (ISVNO)  ,  7) 

AFl  =  EPHEMdNVERS  (ISVNO)  ,  6) 

AF2  =  EPHEMdNVERS  (ISVNO)  ,  5) 

TGD  =  EPHEMdNVERS  (ISVNO)  ,3) 

TOC  =  EPHEMdNVERS  (ISVNO)  ,4) 

DELT  =  AFO  +  AFl* (TC  -  TOC)  + 

AF2*(TC  -  TOC) ^2  +  DELTR  - 

TGD 

T  =  TC  -  DELT 
R  =  AS* (1.0  -  ES*SIN(E) ) 

Compute  satellite  true  anomaly,  NU 
NUM  =  SQRTd.O  -  ES*ES)  *SIN(E)  )  / 
(1.0  -  ES*COS (E) ) 

DENOM  =  (COS(E) -ES) /(l.O- 
ES*COS (E) ) 

NU  =  ATAN2 (NUM,  DENOM) 

W  =  EPHEMdNVERS  (ISVNO)  ,21) 

PHI  =  NU  +  W 


mean  motion  difference 
[semicircle/ s] 

Square  root  of  semi -major  axis 
[m"l/2] 

Semi -major  axis 
Computed  mean  motion 

Mean  anomaly  at  reference  time 
[smcir] 

Mean  anomaly 

E  +  MK  +  ES*SIN(EOLD)  [Newton- 
Raphson] 

Eccentricity 

Kepler's  equation  for  Eccen. 
anomaly 


Eccentricity  anomaly 

Relativistic  correction  term 

7  - 
6  - 
5  - 

3  - 

4  - 

Transit  time 


GPS  time  of  transmission  correction 
Satellite  average  radius  R 

Sin (true  anomaly) 

Cos (true  anomaly) 

Four  quadrant  inverse  tangent 
Argument  of  perigee  [semicircle] 
Argument  of  latitude 


Compute  correction  terms  from  harmonics 

CUS  =  EPHEMdNVERS  (ISVNO)  ,13)  Amplitude  of  sine  harmonic 

correction  term  to  the  argument  of 
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cue  =  EPHEM(INVERS(ISVNO) ,11) 


CRS  =  EPHEM(INVERS(ISVNO) ,8) 
OMEGAO  =  EPHEM ( INVERS ( ISVNO) , 17 ) 
CIS  =  EPHEM (INVERS (ISVNO) , 18) 


CRC  =  EPHEM (INVERS (ISVNO) ,20) 


CIC  =  EPHEM (INVERS (ISVNO) , 16) 


IOTA  =  EPHEM (INVERS (ISVNO) , 19) 


IDOT  =  EPHEM (INVERS (ISVNO) ,23) 

C2PHI  =  COS(2*PHI) 

S2PHI  =  SIN(2*PHI) 

Second  harmonic  perturbations 
DELPHI  =  CUS*S2PHI  +  CUC*C2PHI 
DELR  =  CRS*S2PHI  +  CRC* C2 PHI 
DELI  =  CIS*S2PHI  +  CIC*C2PHI 

PHI  =  PHI  +  DELPHI 
R  =  R  +  DELR 

IOTA  =  IOTA  +  DELI  +  IDOT* (T-TOE) 

OMEGAD  =  EPHEM (INVERS (ISVNO) ,22) 

OER  =  OMEGAO  +  OMEGAD* (T-TOE)  - 
OMEGAE*T 


latitude  [rad] 

Amplitude  of  cos  harmonic 
correction  term  to  the  argument  of 
latitude  [rad] 

Amplitude  of  sine  harmonic 
correction  term  to  orbit  radius  [m] 

Longitude  of  ascending  node  of 
orbit  plane  at  weekly  epoch 

Amplitude  of  sine  harmonic 
correction  term  to  the  angle  of 
inclination  [rad] 

Amplitude  of  cos  harmonic 
correction  term  to  the  orbit  radius 
[m] 

Amplitude  of  cos  harmonic 
correction  term  to  the  angle  of 
inclination  [rad] 

Inclination  angle  at  reference  time 
[semicircle] 

Rate  of  inclination  angle 
[semicir/s] 

Double  angle 


Argument  of  latitude  correction 
Radius  correction 
Corrected  inclination 

Corrected  argument  of  latitude 
Corrected  radius 
Corrected  inclination 

Rate  of  right  ascension 
[semicircle/s] 

Corrected  longitude  of  ascending 
node 


Compute  satellite  ECEF  vector 
(meters) 

ECEFXS(L)  =  R*COS(OER)  *COS(PHI)-  R*SIN (OER) *COS (IOTA) *SIN (PHI) 
ECEFyS(L)  =  R*SIN(OER)  *COS(PHI)+  R*COS (OER) *COS (IOTA) *SIN (PHI) 
ECEFZS(L)  =  R*SIN (IOTA) *SIN (PHI) 


Figure  3.3-2:  Derivation  of  Satellite  ECEF  Coordinates  from  Ephemeris  Data 


Application  ofDGPS  to  L16  Navigation 


Page  34 


3.3.3  Computation  of  Direction  Cosine  Terms 

The  observation  matrix  partial  derivatives  relating  to  the  error  states,  as  described  in 
Equation  (4),  are,  in  fact,  the  direction  cosines  CxSi,  CySi,  CzSi  between  the  local  level  coordinate 
axes  and  the  position  of  each  GPS  satellite  indexed  by  i.  Computation  of  the  direction  cosines 
is  facilitated  by  transforming  the  platform  position  and  that  of  each  satellite  to  local  level 
coordinates,  from  which  the  desired  results  may  be  computed  from  their  difference  vector. 

The  computation  of  platform  ECEF  coordinates  (ECEFXP,  ECEFYP,  ECEFZP)  takes  into 
account  the  elliptical  WGS-84  geodetic  model  as  follows  (Equation  7): 

Rew  ~  Ar/a/i  sin^  A 
ECEFXP  =(REW  +  H)  cos /I  cos(p 
ECEFYP  =(REW  +  H)  cos /I  sin^ 

ECEFZP=  ((1-e^)  REW  +  H)  sin  A 
where  Ar  =  Equatorial  Earth  Radius(ft)  =  2.09257382x10^  ft 

e^  =  Earth's  Ellipticity  Squared  =  6.74499984x  10^  (dimensionless) 

H  =  PlatformAltitude(ft) 


Now  that  both  satellite  and  platform  coordinates  in  ECEF  are  computed,  we  transform 
both  to  Local  Level  coordinates  by  multiplying  by  the  transformation  matrix  Tle  defined  in 
Equation  5,  and  compute  their  difference  vector  DlFF,  as  shown  in  Equation  8: 


LLSAT  = 


LLSAT(l)  ECEFXP 

LLSAT  (2)  =[Tle]  ECEFYP 
LLSAT  (3)  ECEFZP 


LLPLAT  = 


LLPLAT(l)  ECEFXP 

LLPLAT  (2)  =[Tle]  ECEFYP 
LLPLAT  (3)  ECEFZP 


(8) 


DIFF  =  LLSAT  LLPLAT 


The  computation  of  the  desired  direction  cosine  terms  will  then  be  in  terms  of  elements  of  the 
DIFF  vector  defined  above  (Equation  9): 
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CXS  i  =  DIFF(1)/SATRANGE 

CYS  i  =  DIFF  (2)  / SATRANGE  W 

CZS  i  =  DIFF  (3) /SATRANGE 

where  SATRANGE  =  [DIFF(l)^  +  DIFF(2)^+  DIFF(3)^]'^ 


It  should  also  be  noted  that  the  elevation  of  the  satellite  above  the  horizon  may  also  be  computed 
from  these  vector  components.  This  result  will  be  utilized  to  eliminate  all  satellites  that  do  not 
achieve  at  least  five  degrees  of  elevation  from  filter  consideration: 


Satellite  Elevation  Angle  =  tan 


DIFF(3) 

VdIFF(I)^  +  DIFF(2)2 


(10) 
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3.4  Operation  of  DGPS  RF  in  Simulator  or  Terminal  Environment  and  RF 
Kalman  Filter  Design 


The  integration  of  the  DGPS  RF  within  a  simulator  or  terminal  environment  is  based  on 
the  availability  of  a  stable  Link- 16  community  navigation  solution,  since  the  RF  is  designed  to 
compute  corrections  to  this  solution,  and  cannot  operate  without  it.  In  the  case  of  actual  Link-16 
terminal  integration,  the  navigation  solution  is  provided  via  interface  with  embedded  terminal 
navigation  software.  In  the  case  of  a  simulator  environment,  the  navigation  solution  is 
provided  by  one  of  two  Link- 16  navigation  representations:  (a)  A  simple  covariance 
representation  of  a  community  navigation  solution  having  constant  but  arbitrary  position  and 
time  errors  (COV50)  or  (b)  a  comprehensive  simulation  of  Link-16  navigation  performance 
known  as  the  Link-16  Navigation  Simulator  (LNS).  Option  (a)  provides  an  easily  modified 
representation  of  a  mobile  community,  which,  though  not  completely  modeling  all  error  sources, 
nevertheless  provides  a  simple  test  bed  for  preliminary  RF  design  and  integration  studies. 

Option  (b)  embodies  the  actual  Link- 16  OCP  navigation  code  exactly  as  implemented  within  the 
terminal,  and  has  been  proven  over  many  years  to  exactly  replicate  community  error  dynamics. 
Final  performance  estimates  of  DGPS  RF  operation  always  use  the  LNS  as  the  primary 
navigation  reference.  (Please  refer  to  Paragraph  4.1  for  details  on  the  navigation  reference 
software  used  in  each  of  the  program  versions  of  the  DGPS  RF.)  In  the  remainder  of  this 
section,  we  review  the  operational  integration  of  the  DGPS  RG  algorithm  with  the  navigation 
solution  and  the  host  DGPS  input  data  provided  via  a  real  or  simulated  GPS  receiver.  Also 
presented  herein  is  the  formal  definition  of  the  RF  Kalman  Filter  design  utilized  within  this 
program. 

3.4.1  DGPS  RF  Algorithm  -  Data  Specification 

Based  on  the  preceding  sections,  the  input  data  required  for  initialization  and  operation 
of  the  DGPS  RF  may  be  summarized  as  follows: 

(a)  GPS  pseudorange  information  for  all  selected  satellites  at  a  rate  commensurate  with 
the  RF  Kalman  Observation  rate  (1  Hz,  2Hz,  4Hz) 

(b)  Ephemeris  Data,  also  provided  by  the  GPS  Receiver  ( possible  refresh  at  intervals  of 
approximately  30  minutes) 

(c)  Terminal  Initialization  Data  (Master/Slave  Indication)  -  One  time  only 

(d)  Self  Navigation  Data  (Provided  via  LI  6  OCP  or  Simulator)  -  4  Hz  Rate 

(e)  PPLI  messages  from  Master  -  Nominal  Rate  One  per  12  Seconds 

(f)  Master  Reported  Navigation  Data  and  Measured  Pseudorange  Data 

(g)  Time  Reference  for  Time  Tagging  Observation  Data 

The  requirement  for  differencing  self-measured  pseudorange  data  and  that  of  the  master 
platform  dictates  that  a  special  TADIL-J  message,  designated  as  the  Master  Message  must  be 
transmitted  at  intervals  by  the  master  platform  to  provide  the  data  set  denoted  by  (f)  to  all  slave 
platforms.  The  interval  for  this  transmittal  is  subject  to  tradeoffs  between  algorithm  performance 
and  additional  Link- 16  bandwidth  usage.  At  this  writing,  it  is  believed  that  a  suitable 
compromise  for  the  rate  of  Master  Message  transmission  will  be  at  a  2  Hz  rate,  with  either  two  or 
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four  measurement  cycles  worth  of  position  and  pseudorange  data  being  packed  within  each 
message.  This  rate  will  provide  the  fastest  convergence  of  the  RF  algorithm,  measured  in 
seconds.  If,  however,  operational  usage  of  the  DGPS  RF  can  tolerate  convergence  rates  in  the 
order  of  tens  of  seconds,  the  rate  of  the  Master  Message  transmission  can  be  slowed  to  1  Hz,  and 
thus  incur  only  50%  of  the  LI  6  bandwidth  loss.  A  final  decision  on  this  question  will  be 
deferred  to  FY-  04.  The  current  baseline  for  simulation  and  laboratory  testing  remains  at  a  4Hz 
RF  Kalman  Cycle.  It  should  also  be  mentioned  that  the  usage  of  PPLI  information  as  one  of  the 
two  observation  types  is  periodic,  but  in  general  asynchronous  with  the  processing  of 
pseudorange  differences.  The  operation  of  the  DGPS  RF  is  fundamentally  based  upon  the 
Kalman  Cycle,  nominally  4  Hz,  but  reducible  to  2  Hz  or  1  Hz  as  desired. 

Figure  3.4-1  indicates  a  simplified  representation  of  the  data  flow  required  to  support  the 
operation  of  the  DGPS  RF.  It  should  be  noted  that,  with  the  single  exception  of  a  request  to 
transmit  a  Master  Message  (shown  dotted)  and  exercised  for  a  master  platform  only,  no  data 
from  the  DGPS  RF  is  fed  back  to  the  OCP.  The  results  of  the  DGPS  RF  estimation  process  are 
provided  only  to  the  host,  and  are,  likewise,  not  fed  back  to  the  existing  Link- 16  navigation 
computations.  Those  operate  precisely  as  they  are  currently  implemented  within  Link- 16 
terminal  assets. 


Figure  3.4-1:  Simplified  Data  Interface  to  DGPS  RF  Algorithm 
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3.4.2  DGPS  RF  Kalman  Processing  Overview 

The  basis  of  the  DGPS  RF  is  that  of  a  discrete  Extended  Kalman  Filter  (EKF),  operating 
at  a  nominal  Kalman  Observation  Cycle  of  250  milliseconds.  The  theory  of  discrete  Kalman 
Filtering  is  available  in  many  references.  See,  for  example  reference  (5).  A  summary  of  the 
fundamental  processing  equations  for  a  discrete  Kalman  filter  is  given  in  Figure  3.4-2  extracted 
from  reference^. 


System  Model 

Measurement  Model 

Xk=^k  i^k  1+Wk  p  Wk~N(0,Qk) 
Zk  =  HkXk  +  Vk ,  vk  ~  N(0,  Rk ) 

Initial  Conditions 

E[x(0)]  =  xo3[(x(0)]  xo)(xo  Xo)'^]  =  Po 

Other  Assumptions 

E[wkVj^]  =  0  for  all  j,  k 

State  Estimate  Extrapolation 

xk(  )  =  4>k  Ixk 

Error  Covariance  Extrapolation 

Pk(  )  =  4>k  iPk  l(+)4>k  1^+Qk  1 

State  Estimate  Update 

Xk(  )  =  <l>k  Ixk 

Error  Covariance  Update 

Kalman  Gain  Matrix 

Pk(  )  =  ^k  iPk  l(+)4>k  1^+Qk  1 

Figure  3.4-2:  Summary  of  Discrete  Kalman  Filter  Equations 


The  design  of  the  discrete  Kalman  equations  to  the  DGPS  RF  centers  on  the  selection  of 
the  appropriate  observation  matrix  (H),  the  computation  of  the  corresponding  transition  matrix, 
4>a,  the  provision  of  representative  error  models  for  the  two  types  of  potential  observation  (R 
matrix),  and  appropriate  process  noise  models  (Q  matrix).  We  have  previously  specified  the 
configuration  of  the  maximum  state  vector,  X,  in  Equation  (2).  The  error  velocity  terms  (states 
2, 4,  and  6)  were  initially  included  in  the  DGPS  RF  design  and  evaluated  for  effectiveness  (See 
Paragraph  XXX  for  details).  The  configuration  of  the  transition  matrix,  Oa,  can  thus  have  two 
possible  forms,  one  not  including  the  velocity  states,  and  one  where  the  states  are  included.  The 
resultant  form  for  matrix  4>a  in  both  cases  are  given  in  equation  11: 

The  elements  of  the  observation  matrix  (H)  have  previously  been  specified  in  Equation  4. 
The  H(l,l),H(l,3),and  H(l,5)  terms  applied  to  range  processing  derived  from  PPLI 
measurements  will  be  set  to  zero  for  all  Kalman  cycles  for  which  a  PPLI  from  the  master  has  not 
been  received.  For  cycles  in  which  a  PPLI  is  present,  those  terms  will  be  computed  using  the 
expressions  in  Equation  4.  The  terms  H(k,l),  H(k,3),  H(k,5),  and  H(k,7)  will  usually  be  nonzero 
for  all  Kalman  cycles  for  all  k  over  the  range  (2  .. .  NVS  +  1),  where  NVS  is  number  of 
processed  satellites  in  any  given  cycle. 
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The  detailed  specification  of  the  Initial  state  covariance  matrix  (P),  the  Observation  Noise 
Matrix  R,  and  the  Process  Noise  Matrix  (Q)  may  be  found  in  the  DGPS  RF  Software 
Requirements  Specification,  presented  in  Appendix  A. 


1  000000  0 
0000000  0 
00  1  0000  0 
-  00000000 

=00001000  ®A= 

0000000  0 
0  0  0  0  0  0  1  At 
0000000  1 


1  At  0  0  0  0  0  0 
0  1  0  0  0  0  0  0 
0  0  1  At  0  0  0  0  (11) 

0  0  0  1  0  0  0  0 

0  0  0  0  1  At  0  0 

00000100 
0  0  0  0  0  0  1  At 

0  0  0  0  0  0  0  1 


Transition  Matrix  - 
No  Velocity  Terms 


TransitionMatrix  - 
VelocityTerms  Present 
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4.  Methods  and  Procedures 


The  purpose  of  this  section  is  to  present  a  comprehensive  account  of  the  design  studies 
and  analyses  conducted  during  the  FY03  phase  of  the  DGPS  RF  contract.  The  primary  focus  of 
these  efforts  centered  on  the  analysis  and  simulation  of  the  basic  DGPS  RF  algorithm  on  a  series 
of  simulation  test  bed  programs.  The  result  of  this  development  process  was  a  robust  and 
effective  algorithm  capable  of  meeting  the  performance  goals  set  at  the  project’s  beginning. 
However,  the  FY  03  program  had  goals  beyond  the  definition  and  development  of  the  algorithm 
itself.  Since  the  FY04  program  anticipates  laboratory  demonstration  of  the  algorithm  integrated 
within  a  Link- 16  terminal  and  exercised  on  the  Terminal  ATP  Test  Set  (TATS),  a  significant 
amount  of  study  and  effort  was  expended  on  the  formal  specification  of  real  time  RF  software 
via  a  Software  Design  Document  (SDD).  The  SDD  was  a  necessary  first  step  for  the  generation 
of  Operational  Code  suitable  for  inclusion  within  the  terminal,  as  well  as  the  design  of  code 
changes  to  the  existing  OCP  needed  for  integration  with  the  RF.  Finally,  modifications  to  the 
TATS  itself  to  accommodate  the  satellite  pseudorange  measurements  and  the  generation  of  the 
Master  Message  were  also  required.  The  objective  of  all  these  efforts  was  a  comprehensive 
implementation  plan  for  near-operational  level  software  design  and  test  equipment  capabilities  to 
enable  coding  to  begin  immediately  after  FY04  begins  in  October  2003. 

At  the  inception  of  this  project,  it  became  apparent  that  several  different  versions  of  the 
software  algorithm  were  necessary.  The  first  of  these.  Version  1.0,  was  designed  to  function 
entirely  within  a  simulation  environment  (laptop  or  PC).  Therefore,  all  algorithm  interfaces  with 
the  supporting  community  navigation  solutions  and  GPS  pseudorange  measurements  were 
provided  via  software  generation  of  the  needed  interface  data.  The  laboratory  test  version  of  the 
DGPS  RF  algorithm.  Version  2.0,  was  expressly  designed  for  inclusion  within  the  terminal. 
Community  navigation  inputs  required  by  the  DGPS  RF  algorithm  will  now  be  derived  directly 
from  the  terminal  operational  software,  rather  than  via  digital  simulation.  Furthermore,  in  the 
interest  of  testing  a  near-operational  version  of  the  software,  the  laboratory  TATS  pseudorange 
inputs  will  be  derived  from  a  full  elliptical  satellite  model,  rather  than  the  circular  model  used  in 
V.l.  The  projected  Version  3.0  of  this  software  will  be  a  fully  flight  qualified  design  that  will 
differ  from  V.2  only  in  the  details  of  the  GPS  host  pseudorange  data  transfer.  Integration  with  a 
real  vs.  simulated  GPS  receiver  will  take  place  for  V3.0.  It  is  significant  to  note  that  with  the 
exception  of  the  OCP  and  navigation  interface  design,  all  three  versions  of  the  algorithm  share 
common  code  for  the  algorithm  implementation. 


4.1  Description  of  DGPS  RF  Software  Versions 

Each  of  the  software  versions  of  the  DGPS  RF  was  designed  for  a  specific  operating 
environment  and  was  tailored  to  support  specific  simulation  and  testing  objectives.  Version  1.0 
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was  designed  to  operate  within  a  PC  or  laptop  environment  and  had  as  its  primary  objective  the 
determination  of  basic  algorithm  performance  and  operating  characteristics.  Version  2.0  is  the 
version  of  the  test  software  tailored  for  terminal  operation  within  a  laboratory  test  environment. 
A  projected  Version  3.0  also  operates  within  a  terminal  environment,  but  will  be  designed  to 
function  as  a  flight  test  enabler  using  an  engineering  pallet  within  an  actual  test  aircraft.  The 
structure  and  organization  of  each  of  these  versions  is  described  below. 

4.1.1  DGPS  Version  1.0 

The  architecture  of  the  DGPS  RF  algorithm,  in  all  program  versions,  is  built  around 
seven  core  Computer  System  Components  (CSCs),  whose  titles  and  general  functionality  are 
presented  in  Table  4. 1.1-1.  A  detailed  design  description  of  each  of  these  CSCs  is  discussed  in 
paragraph  4.3. 


CSC 

Description 

RF_EXEC_CTRL 

Controls  the  data  flow  within  Refinement  Processing 
depending  on  inputs  to  the  system. 

RF_SOURCE_DATA_PROCESSING 

Prepares  and  synchronizes  all  data  for  Kalman 
filtering. 

RF_KALMAN_PROCESS ING 

Applies  Kalman  filtering  to  the  data  passed  from 
the  RF_SOURCE_DATA_PROCESSING  unit. 

HOST_INTERFACE_PROCESS ING 

Interfaces  with  host  and  processes  data  that  enters 
this  system  from  the  host,  mainly  control  signals 
and  GPS  data. 

OCP_INTERFACE_PROCESSING 

L16  OCP  interface  from  which  all  OCP  data  enters 
the  system,  mainly  navigation  solution  including 
position,  velocity,  and  time. 

BUILD_MASTER_MESSAGE 

Called  if  the  platform  is  designated  the  master  of 
the  network  from  the  host.  The  master  message  is 
sent  at  a  2  Hz  rate  to  all  the  slaves  in  the 
network . 

BUILD_RF_RESULTS_MESSAGE 

Outputs  DGPS  RF  solution,  status,  and  covariance  to 
host  computer. 

Table  4.1-1:  DGPS  RF  Computer  Software  components  and  description 


Operation  of  the  core  modules  within  the  DGPS  RF  algorithm  requires  the  establishment 
of  both  Operational  Computer  Program  (OCP)  and  host  interfaces.  The  OCP  interface 
comprises  the  (simulated  or  real)  availability  of  pseudorange  measurements  and  master 
navigation  solution  provided  by  a  (simulated  or  real)  Master  Message  transmitted  from  the 
master,  and  the  navigation  solution  of  the  host  platform.  The  host  interface  requires  the 
provision  of  (simulated  or  real)  GPS  own  platform  pseudorange  measurements,  GPS  ephemeris 
data,  and  certain  control  inputs. 
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A  comprehensive  interface  description  of  the  data  transfer  across  these  interfaces  for  all  software 
versions  is  presented  in  Figure  4.1-1 


NAV 

Reference 

OR 

LINK-16 

OCP 


POWER  OPS 
DISrRF  ^ 


MMS  (2,  3, 4) 

MASTER.MSG  (2,  3,  4)  ^ 

MS_IND  (2,  3,  4) 

EST_SNAV  (2,  3,  4) 

SNAV_VAL_IND  (2.  3,  4)  ^ 

MS_IND  (2,  3,  4) 

TRUE_SNAV(1,2) 

TRUE_MNAV  (1,  2) 

TRUE_CL0CK_BIAS(I,2)  ^ 

TRUE_FREQ_DRIFT  (1.2)  ^ 

PPLLDATA  (4) 

RTT.DATA  (4) 

CSCLVERSION  ( 1 ,  2,  3,  4)  ^ 

MASTER_MSG  (2,  3,  4) 

POWER,  DISCRETES 
FROMRPS 


Pilot 


0.0 


RF_OPR_SW  (2,  3,  4) 


SELF_GPS_DATA  (2,  3,  4) 


RF_ENABLE  (2,  3.  4) 


GPS_VAL_IND  (2,  3, 4) 


EPHEM_DATA  (2,  3,  4) 


RF_HEALTH_STATUS_MSG  , 


(1,2, 3, 4) 
RF_RESULTS_DATA  (4) 


HOST 


Because  for  the  differing  data  requirements  of  the  four  software  versions,  certain  operation  of  data 
paths  will  be  represented  as  a  function  of  the  CSCI  Version  indicator.  These  paths  are  labeled  as  to 
version  usage  via  a  subset  of  the  integers  (1,  2,  3, 4),  where  each  number  designates  the  version(s) 
that  data  element  will  be  required. 


Figure  4.1-1:  DGPS  RF  Core  Interfaces 


Within  the  DGPS  RF  Version  1.0,  the  OCP  interface  is  provided  by  community 
navigation  simulation  software  that  generates  the  estimated  and  true  navigation  solutions  of  the 
simulated  community.  The  community  navigation  capability  was  provided  by  one  of  two 
navigation  software  packages  designed  and  developed  by  BAE  SYSTEMS.  The  first,  and 
simplest  of  these  was  a  navigation  simulator  designated  as  COV50,  which  was  a  covariance- 
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based  software  package  developed  prior  to  this  project  as  a  “quick-look”  estimator  of  community 
navigation  performance.  This  program  was  used  in  the  early  development  stages  of  the  project 
due  to  its  ease  of  use  and  modification,  as  well  as  its  non-proprietary  status.  The  second,  and 
more  complex  navigation  model  used  to  provide  the  community  navigation  solution  was  the 
Link-16  Navigation  Simulator  (LNS).  This  proprietary  BAE  SYSTEMS  product  was  used  for 
detailed  performance  studies  due  to  the  fidelity  with  which  it  represents  the  true  error 
characteristics  of  a  mobile  LINK-16  community.  Appendix  B  provides  a  listing  of  COV50,  as 
well  as  a  description  of  the  primary  attributes  and  capabilities  of  the  LNS.  It  should  be  noted  at 
this  point  that  the  LNS  is  mandated  to  track  the  operational  navigation  code  implemented  within 
Link- 16  assets,  and  must  be  considered  the  primary  reference  in  all  questions  of  Link- 16 
community  navigation  performance. 

The  GPS  satellite  dynamic  profile  in  Version  1.0  was  provided  by  the  simple  circular 
satellite  prediction  algorithm  described  in  paragraph  3.3.1.  For  operation  of  the  DGPS  RF 
Version  1.0,  we  note  that  either  the  COV55  program  or  the  LNS  was  used  to  provide  the 
community  navigation  solutions  required  by  the  algorithm.  When  the  COV55  program  was 
utilized,  we  will  designate  the  composite  program  as  Test  Bed  1.  When  the  full  LNS  is  installed, 
we  designate  the  composite  program  as  Test  Bed  2.  Figures  4.1-2  and  4.1-3  present  simplified 
schematics  of  the  interfaces  implemented  within  Test  Beds  1  and  2. 


Laptop/PC  operating  environment 


Figure  4.1-2:  V.1.0  configuration  for  Test  Bed  1 
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Test  Bed  1,  which  provides  dynamic  community  error  trajectories  but  constant 
navigation  error  profiles  was  used  during  the  early  months  of  the  project  for  fundamental 
algorithm  design,  test,  and  experimentation.  In  contrast.  Test  Bed  2,  which  provided  realistic 
community  navigation  error  profiles,  was  used  to  determine  algorithm  performance  levels  under 
a  wide  variety  of  conditions.  Paragraph  4.2  provides  full  details  of  the  testing  and  analysis 
performed  using  these  two  programs.  Test  Bed  2  is  the  basis  for  the  interim  PC  demonstration 
scheduled  for  September  2003. 


4.1.2  DGPS  RF  Version  2.0 

Version  2.0  of  the  DGPS  RF  is  designed  for  integration  and  real-time  execution  within  an 
actual  Link- 16  terminal  in  a  laboratory  environment.  Version  2.0,  integrated  with  the  Link- 16 
Operational  Computer  Program  (OCP)  will  operate  on  BAE  SYSTEMS  Terminal  ATP  Set 
(TATS),  which  provides  a  real  time  testing  environment  for  Link-16  terminal  assets.  The  TATS 
environment,  more  fully  discussed  in  paragraph  4.5,  supports  Link-16  testing  by  providing  the 
Terminal  Under  Test  (TUT)  with  host  and  RF  inputs  that  such  a  unit  would  see  in  actual  flight 
operation.  Under  the  control  of  a  scenario  tape  (now  in  CD  format),  the  supporting  test  terminal 
provides  actual  message  traffic  that  would  be  present  in  a  test  community.  The  LRU  interface 
provides  simulated  host  inputs,  such  as  control  and  INS  acceleration  data  needed  to  support  the 
terminal’s  normal  operation.  For  the  operation  of  the  DGPS  RF  program,  however,  certain 
inputs  not  presently  supported  by  the  TATS  must  be  developed  and  supplied  to  the  terminal. 
These  inputs  include  pseudorange  data  provided  by  a  GPS  satellite  model,  control  inputs,  and  the 
generation  of  Master  Messages  from  the  simulated  master  platform.  Note  that  the  TUT  will 
always  be  representing  a  slave  unit  in  this  environment. 

Unlike  Vl.O,  in  which  community  and  self-navigation  is  provided  by  either  the  COV55 
or  the  LNS  navigation  programs.  Version  2.0  is  fully  integrated  within  the  Link- 16  CORE 
software  package,  and  receives  all  necessary  interface  information  from  the  embedded  software 
package  in  which  it  operates.  (Figure  4.1-4)  Please  note  that  during  the  testing  of  the  DGPS  RF 
code,  the  TUT  is  executing  its  navigational  function,  processing  received  PPLI  and  RTT 
messages  as  part  of  its  normal  operation. 

Figure  4. 1.2-1  presents  a  simplified  block  diagram  of  the  MIDS  LVTl  terminal,  and 
shows  the  location  of  the  OCP  within  the  terminal  data  processor.  In  the  expansion  diagram  of 
the  Link-16  OCP,  it  is  seen  that  the  DGPS  RF  V2.0  will  be  embedded  within  this  software  load, 
and  will  include  both  RF  OCP  and  RF  host  interface  code.  Host  data  that  is  required  by  the  RF 
will  pass  through  the  physical  host  interface,  located  in  the  (unchanged)  Tailored  I/O  Module. 

RF  interface  data  passing  through  this  processor  will  be  routed  to  the  (software)  Host  I/O 
processing  for  later  submission  to  the  RF  algorithm. 
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MIDS  LVTl  OCP 


VME  Bus  to/from  TaUored  I/O  (Physical  Host  Interface) 


Figure  4.1-4:  Embedding  of  V2.0  within  MIDS  LVTl  OCP 
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In  contrast  to  Version  1.0,  which  uses  a  circular  satellite  model,  Version  2.0  is  designed 
to  use  the  full  elliptical  satellite  model,  whose  data  must  be  supplied  by  the  TATS  equipment  as 
described  in  paragraph  4.5.  This  simulated  pseudorange  data  will  be  furnished  to  the  TUT  in  the 
format  of  a  typical  military  GPS  receiver,  in  this  case,  the  Canadian  Marconi  NORTHSTAR 
unit.  In  this  regard.  Version  2.0  is  very  close  to  being  operable  with  actual  satellite  units. 

Version  2.0,  as  implemented  within  a  Link-16  terminal  on  the  Terminal  ATP  Test  Set  will  be 
used  for  the  final  FY04  phase  demonstration  in  March  2004. 

4.1.3  DGPS  Version  3.0 

Version  3.0  is  the  designation  for  a  potential  flight-qualified  version  of  the  DGPS  RF 
software,  should  the  scope  of  this  project  be  expanded  to  incorporate  flight-testing.  As  such,  it 
will  be  designed  to  operate  with  an  arbitrary  GPS  receiver  set,  a  (provisional)  data  link 
processor  connecting  the  Link- 16  terminal,  GPS  receiver,  and  a  data  recording  device.  Nominal 
configurations  of  both  ground  and  airborne  equipment  suites  are  indicated  in  Figure  4-5. 

In  contrast  with  the  test  configuration  of  V2.0,  which  derives  its  INS  acceleration 
measurements,  GPS  pseudorange,  and  PPLI  messages  from  the  TATS,  V3.0  will  interface  with 
actual  INS  and  GPS  units,  and  all  messages  utilized  will  be  physically  generated  via  the  Link- 16 
terminals.  As  was  the  case  with  Version  2.0,  both  Link-16  terminal  units  will  be  supporting 
their  navigational  functions  just  as  they  do  in  normal  operation.  DGPS  RF  solution  data  will  be 
supplied  to  the  recording  apparatus  for  further  analysis,  but  in  no  event  will  such  solutions  be  fed 
back  to  the  Link- 16  navigation  processing. 

4.1.4  DGPS  Version  4.0 

A  parallel  research  program  performed  by  BAE  SYSTEMS  for  ONR,  called 
Improvement  of  T.ink-16  Navigation  via  Real-Time  Atmospheric  Modeling  is  directed  at 
improving  Link- 16  navigation  through  improved  estimation  of  atmospheric  propagation  effects. 
To  this  end,  a  new  algorithm  designated  as  the  Atmospheric  Filter  (AF)  was  designed  and 
tested.  The  goal  of  this  model  was  to  yield  an  order  of  magnitude  or  better  of  estimation 
accuracy  for  PPLI  message  TOA  measurements.  The  designation  DGPS  V4.0  is  a  placeholder 
for  a  potential  software  package  that  could  combine  the  capabilities  of  DGPS  V3.0  with  the  AF 
algorithm  range  measurement  improvement.  The  goal  of  this  combination  would  be  to  exploit 
the  synergy  of  these  two  algorithms  to  provide  superior  navigation  capability  to  a  mobile 
community  in  the  event  that  GPS  capability  was  jammed  or  otherwise  unavailable.  This  hybrid 
configuration  is  not  currently  under  consideration  by  ONR  or  other  agencies. 
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4.2  Test  Bed  1  Simulation  Activities 

Overview  and  Rationale 


The  overall  objective  of  the  series  of  simulations  performed  with  Test  Bed  1  was  to 
provide  a  baseline  analysis  of  the  capabilities  of  the  DGPS  RF  algorithm,  and,  more  specifically, 
to  determine  if  the  performance  goals  of  the  DGPS  program  (i.e.  <  1  meter  positioning,  <  1  ns 
time  synchronization)  were  supportable.  Within  the  FY03  activities,  the  Test  Bed  1  simulation 
study  was  the  first  systematic  research  performed  into  the  sensitivities  of  the  DGPS  RF 
algorithm.  Although  this  was  the  first  formal  study  of  the  DGPS  RF  algorithm,  it  was,  in  fact, 
preceded  by  related  studies  performed  during  April  -  August  2001 under  the  DARPA-sponsored 
PATS  program,  in  collaboration  with  BAE  SYSTEMS  lEWS  of  Nashua,  NH.  The  goal  of  this 
program  was  to  combine  extremely  precise  community  positioning  and  time  synchronization 
with  innovative  signal  processing  and  geolocation  algorithms  for  accurate  location  of  hostile 
radar  emitters. 

The  initial  design  of  the  DGPS  algorithm  was  performed  for  PATS  under  severe  financial 
and  time  constraints,  which  provided  no  opportunity  to  conduct  a  systematic  study  of  the 
algorithm’s  capabilities.  Using  an  early  version  of  the  COV50  navigation  simulator,  a  small 
number  of  quick  reaction  simulations  produced  promising  early  results  that  indicated  the 
potential  of  DGPS  for  reducing  position  and  time  errors  to  small  levels.  Figure  4.2-1  is  an 
example  of  the  results  obtained  during  PATS  simulation  studies.  Under  the  terms  of  the  PATS 
program,  BAE  SYSTEMS  was  directed  to  evaluate  the  performance  of  the  DGPS  algorithm 
using  recorded  GPS  satellite  pseudorange  data  collected  by  S  AIC  in  Arizona  during  flight  tests 
performed  in  spring  2000.  These  studies  were  the  first  application  of  the  use  of  the  elliptical 
satellite  ECEF  algorithms  for  the  DGPS,  and  resulted  in  mathematically  stable  and  consistent 
position  error  determinations.  Although  no  reference  solution  accurate  enough  to  verify  these 
results  was  available,  the  resulting  position  solutions  agreed  with  recorded  pseudorange  data  to 
well  within  a  meter.  (Figure  4.2-2) 
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Figure  4.2-1:  Refinement  FOter  nominal  performance 
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Figure  4.2-2:  Refinement  Filter  Performance  with  Recorded  GPS  Data  -  Mission  10/DweIl  11 

The  above  results,  although  encouraging,  provided  very  few  reference  points  to 
determine  algorithm  performance  under  varying  conditions  of  initial  errors,  observation  rates, 
and  Kalman  Filter  tuning  conditions.  It  is  for  this  reason  that  the  Test  Bed  1  series  was  designed 
to  evaluate  performance  of  the  algorithm  under  carefully  controlled  error  characteristics. 
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Parameter  Test  Space  for  Test  Bed  1  Studies 

The  Test  Bedl  simulation  series  was  designed  to  investigate  performance  of  the  DGPS 
algorithm  while  varying  key  algorithm  parameters.  A  list  of  the  key  parameters  that  were  varied 
and  their  test  limits  is  presented  in  Table  4.2-1 


Parameter  Type 

Allowable  Ranges 

Comments 

a)  Link- 16  Position  Errors 

ex,  ey,  ez  =  2, 20, 200,2000 

Normal  LI 6  Position 
Errors  <  100  ft. 

b)  Link- 16  Velocity  Errors 

eVx,  eVy  =  0,1,2  ft/sec 

Normal  LI 6  Velocity 
Errors  <  1  ft/sec 

c)  Time  Base  Clock  Bias  & 
Frequency  Drift 

eBc  =  0, 200  ns 

efc  =  0, 10  ns/sec 

Normal  GPS  time 
errors  <  40  ns 

d)  DGPS  Kalman  Filter 
Observation  Rate 

1  Hz,  2  Hz,  4  Hz 

- 

e)  DGPS  Kalman  Filter 
Covariance  (initial) 

Pos.  States  =  (1000  ft)^ 

Vel.  States  =  (1  ft/sec)^ 
Clock  Bias  =  (100  ns)^ 
Freq.  Drift  =  (10  ns/s)^ 

Exceptions  as  noted 
for  large  initial 
errors 

f)  DGPS  Kalman  filter 
Process  Noise 

Position  =  (1000  ft)^ 

Velocity  =  (0.2  ft/s)^ 
When  velocity  states 
present 

- 

g)  Use  of  Velocity  States 

N/A 

States  2, 4, 6  included 
where  indicated 

Table  4.2-1:  Range  limits  of  RF  test  parameters 


Performance  of  the  DGPS  algorithm  when  the  above  parameters  were  varied  was 
evaluated  against  the  desired  position  and  time  estimation  results.  In  addition,  the  solution 
stability  and  robustness,  though  more  difficult  to  quantify  precisely,  was  a  further  metric  against 
which  performance  in  each  case  was  graded. 
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Measurement  Variance  Values 

Values  assumed  for  all  test  conditions  for  the  measurement  observation  variances  were: 

R(l,l)  =  Variance  of  PPLI  Range  Measurement  =  (21.0  ft)* *2 
R(2,2)  =  Variance  of  GPS  Pseudorange  =  (4.0  ft)**  2 


T. ink- 16  Community  cuid  Navigation  Solution 

The  Link- 16  community  for  these  runs  was  restricted  to  two  members,  namely  the  master 
and  slave  platforms,  since  the  DGPS  RF  only  considers  the  relative  errors  between  these  two 
platforms.  A  fundamental  requirement  for  the  initiation  of  a  DGPS  RF  solution  is  the  prior 
establishment  of  a  stabilized  Link- 16  navigation  solution  within  the  participating  community.  It 
is  assumed  that  the  Link- 16  navigation  algorithm  operates  in  a  conventional  manner,  that  is, 

PPLI  messages  at  a  rate  of  once  per  12  seconds  are  transmitted  by  the  master,  and  processed  by 
the  slave.  In  addition,  it  is  also  assumed  that  both  members  utilize  GPS  PVT  data  at  intervals  of 
12  seconds  as  inputs  to  their  Navigation  Kalman  Filter. 

The  trajectory  assumed  for  the  participating  community  is  depicted  in  Figure  4.2.1  -  3, 
below.  Both  aircraft  are  assumed  to  fly  at  a  constant  speed  of  800  feet  per  second.  The  master 
aircraft  begins  the  trajectory  at  a  position  of  45  degrees  north  latitude,  45  degrees  west  longitude, 
and  traverses  the  racetrack  pattern  in  a  clockwise  manner.  The  slave  aircraft  begins  at  a  position 
of  44.8  degrees  latitude,  and  45  degrees  longitude,  and  traverses  the  flight  pattern  in  a  counter¬ 
clockwise  pattern. 

For  Test  Bed  1  simulation,  navigation  errors  are  varied  for  each  run,  and  include  constant 
position  error  and/or  constant  velocity  errors.  Please  note  that  these  are  the  relative  position 
errors  in  the  Link- 16  solution  that  the  DGPS  is  designed  to  estimate. 
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Figure  4.2-3:  Flight  trajectory  of  Master  and  Slave  platforms  in  a  two  member  community 


Application  of  DGPS  RF  Results  -  Open  vs.  Closed  Loop 

There  are  two  possible  approaches  to  application  of  the  results  of  the  DGPS  RF 
algorithm,  which  we  refer  to  as  Open  Loop  and  Closed  Loop.  In  the  case  of  Open  Loop,  we 
maintain  the  best  estimates  of  the  Link- 16  navigation  errors  exclusively  within  the  DGPS  RF 
Kalman  Filter  in  the  estimated  state  values,  and  produce  a  “best  composite  estimate”  of  member 
navigation  outside  the  two  filters  in  the  host  computer.  In  the  case  of  Closed  Loop,  we 
periodically  pass  the  DGPS  corrections  back  to  the  Link- 16  Navigation  Kalman  Filter,  and  zero 
the  corresponding  error  state  estimates  of  the  DGPS  _RF.  Both  of  these  approaches  were 
evaluated  within  the  Test  Bed  1  simulations,  and  the  approach  that  was  selected  for  use  was  the 
Open  Loop.  There  are  many  reasons  for  this  choice.  As  will  be  fully  explained  in  later  sections, 
the  Closed  Loop  approach  results  in  long-term  solution  instability,  which  is  not  present  when 
using  the  Open  Loop  approach.  In  addition,  by  combining  the  estimates  of  two  Kalman  Filters  in 
anything  less  than  a  fiilly  optimal  fashion,  serious  Link- 16  navigation  stability  issues  are  likewise 
raised.  Therefore,  for  logistical  and  technical  reasons_we  would  prefer  to  leave  the  operation  of 
the  trusted  and  reliable  Link- 16  navigation  algorithm  untouched,  and  combine  the  results  of  both 
filters  off-line  from  both  estimators. 
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Preview  of  Test  Bed  1  Simulation  Results 

Execution  of  the  Test  Bed  1  studies  ultimately  resulted  in  a  stable,  robust  algorithm  that  satisfied 
all  performance  goals.  During  the  course  of  the  study,  several  significant  design  rules  for  the 
DGPS  RF  algorithm  were  formulated  and  verified,  as  follows: 

(a)  Use  of  Closed  Loop  application  of  RF  corrections  appears  to  yields  long-term 
instability  in  nearly  all  cases.  In  some  cases,  the  solution  instability  takes  hundreds 
or  thousands  of  seconds  of  simulation  time  to  appear.  Use  of  Open  Loop  application 
always  yields  a  stable  and  reliable  solution. 

(b)  The  use  of  the  three  velocity  error  states  within  the  DGPS  RF  is  ineffective  in  both 
Closed  Loop  and  Open  Loop  operation.  In  the  former  case,  highly  oscillatory 
solutions  can  result,  while  in  the  latter  case,  no  significant  difference  was  observed  in 
performance  whether  the  velocity  states  are  present  or  not. 

(c)  The  resulting  DGPS  RF  algorithm  was  virtually  insensitive  to  the  magnitude  of  the 
Link- 16  navigation  position  error.  Excellent  convergence  resulted  even  in  the  case  of 
initial  errors  an  order  of  magnitude  or  more  (i.e.  >  1000  feet/axis)  then  nominal  Link- 
16  performance.  Unmodeled  velocity  errors  under  two  feet/second  per  axis  (large 
compared  to  nominal  Link- 16  hybrid  performance)  similarly  had  little  or  no  effect. 

(d)  The  DGPS  algorithm  was  virtually  insensitive  to  the  magnitude  of  the  initial  clock 
bias  and  frequency  drift  errors  up  to  200  ns  and  10  ns/second  provided  the  initial 
covariance  values  covered  the  actual  error. 

(e)  Convergence  of  the  DGPS  RF  was  shown  to  be  a  function  of  observation  rate, 
although  in  a  highly  nonlinear  fashion.  Best  performance,  of  course,  was  achieved 
at  a  4Hz  pseudorange  observation  rate  with  convergence  in  a  few  seconds  the  norm. 
Conversely,  stretching  the  observation  rate  to  1  Hz  increased  convergence  time  to  SO¬ 
SO  seconds,  depending  on  size  of  initial  errors. 

(f)  Little  sensitivity  was  noted  with  respect  to  initial  KF  state  covariance  values 
provided  they  were  large  enough  to  exceed  true  state  errors. 

In  general,  filter  worked  well  when  covariance  values  exceeded  actual  errors  by  large  margins. 
Corollary:  High  process  noise  modeling  kept  filter  window  open  in  all  cases  and  resulted  in 
stable  operation. 

Full  discussion  of  all  of  the  above  conclusions  is  provided  in  the  analyses  of  each  of  the  test 
cases,  which  constituted  this  portion  of  the  design  study. 


EZ  (feet)  EX  (feet) 


Application  of  DGPS  to  LI  6  Navigation 


Page  53 


4.2.1  Test  Case  1-1  (Closed  Loop)  Baseline  Test  -  Small  Initial  Position  Errors 

The  objective  of  this  test  case  was  to  attempt  to  replicate  the  error  trends  established 
during  previous  research  as  shown  in  Figure  4.2-1.  For  this  case,  the  observation  rate  matched 
that  of  the  reference  run,  with  a  1  Hz  DGPS  RF  update  rate.  No  velocity  states  were  utilized  in 
this  run. 

Initial  Conditions 

Link-16  Position  Errors:  (ERRX,  ERRY  =  2  feet) 

Clock  Bias  Error  (50.0  ns) 

Frequency  Error  (0.0  ns/sec) 


Time  (sec)  Time  (sec) 

Figure  4.2-4:  Closed  Loop  Baseline  Test 
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Analysis  of  Results 

The  solutions  shown  above  bear  a  close  resemblance  to  the  results  presented  in  Figure 
4.2-1  during  the  first  200  seconds  with  respect  to  both  the  position  errors  and  clock  bias  errors. 
These  results  indicated  a  filter  convergence  time  constant  for  a  1  Hz  update  rate  of 
approximately  50  seconds,  which  is  the  case  here  as  well.  In  the  reference  case,  however,  the 
solution  extended  only  to  a  time  of  150  seconds,  so  any  potential  solution  instability  did  not  have 
time  to  occur.  In  the  present  case,  it  is  clear  that  there  is  a  condition  of  instability  that  causes  the 
divergence  of  the  solution  to  occur  at  approximately  230  seconds.  The  probable  cause  of  this 
instability  was  the  closed  loop  feedback  of  the  DGPS  estimated  errors  into  the  Link- 16  error 
values.  Note  that  the  Link- 16  Kalman  Filter  was  not  involved  in  this  process,  since  only  a 
covariance  model  of  the  position  errors  was  in  use.  However,  the  presence  of  this  solution 
feedback  within  the  DGPS  RF  clearly  has  the  potential  to  destabilize  the  solution.  We  wish  next 
to  investigate  whether  an  increase  in  the  observation  rate  from  the  1  Hz  value  used  here  to  2Hz 
or  4  Hz  can  stabilize  the  solution.  As  the  results  presented  in  the  next  paragraph  indicate, 
however,  the  problem  will  persist  as  long  as  closed  loop  operation  of  the  DGPS  RF  is 
maintained. 
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4.2.2  Test  Case  1-2  (Closed  Loop)  2Hz,  4Hz  Update  Rates 

The  objective  of  this  test  case  was  to  investigate  whether  or  not  higher  update  rates  (2Hz, 
4Hz)  would  stabilize  RF  operation  in  a  closed  loop  mode.  No  velocity  states  were  used  in  these 
runs. 

Initial  Conditions 

Link- 16  Position  Errors  (ERRX,  ERRY  =  2  feet) 

Velocity  Errors:  Oft/sec. 

Clock  Bias  Error  (50  ns) 

Velocity  States  -  Not  Present 


Time  (sec)  Time  (sec) 


Figure  4.2-5:  2Hz  update  rate 


EZ  (feet)  EX  (feet) 
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North  Position  Error 


Height  Error 


East  Position  Error 


Figure  4.2-6:  4Hz  update  rate 


Analysis  of  Results 

The  effect  of  increasing  the  observation  rate  to  2  Hz  (Figure  4.2-5  ),  and  4  Hz  (4.2-6) 
indicate  that  more  rapid  updates  increase  the  rate  of  filter  convergence.  In  the  case  of  2  Hz 
updates,  the  estimation  errors  are  driven  to  near  zero  within  about  20  seconds,  while  in  the  case 
of  4  Hz  updates,  the  convergence  time  is  5-6  seconds.  However,  in  both  cases,  increasing  the 
rate  of  observations  does  not  solve  the  closed  loop  stability  problem,  and  results  diverge  at  nearly 
the  same  time  (230  seconds)  that  was  noted  in  the  previous  test  case.  It  is  therefore  clear,  that 
increasing  observation  rate  alone  does  not  solve  the  stability  problem  noted  in  closed  loop 
operation. 
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4.2.3  Test  Case  1-3  (Closed  Loop)  Effect  of  unmodeled  Velocity  Errors,  No 
Velocity  States 

The  objective  of  this  test  case  is  to  investigate  the  effect  on  solution  stability  of 
unmodeled  Link- 16  velocity  errors  when  no  velocity  states  are  included  within  the  DGPS  RF 
model.  For  this  case,  we  provide  north  and  east  velocity  errors  of  1  foot  per  second  in  the  Link- 
16  navigation  solution,  which  represents  an  extremely  high  value  not  likely  to  be  experienced 
during  normal  operation.  A  1  Hz  observation  rate  is  assumed  for  this  test  case. 

Initial  Conditions 

Link- 16  Position  Errors  (ERRX,  ERRY  =  2  feet) 

Link-16  Velocity  Errors  (EVN,  EVE  =  1  foot/sec) 

Clock  Bias  Error  (50  ns) 

Frequency  Error  (0.0  ns/sec.) 

Velocity  States:  Not  Present 


Graphical  Results 


North  Position  Error 


East  Position  Error 


Clock  Bias 


Figure  4.2-7:  Unmodeled  velocity  errors,  no  velocify  states 
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Analysis  of  Results 

The  destabilizing  effect  of  unmodeled  velocity  errors  in  closed  loop  operation  is  obvious 
from  the  results  shown  above.  Although  the  filter  drives  the  errors  to  near  zero  values  as  in  Test 
Case  1-1  within  50  seconds,  these  errors  are  seen  to  grow  almost  immediately ,  and  the  solution 
diverges  dramatically  thereafter.  The  presence  of  unmodeled  velocity  errors  in  closed  loop 
operation  without  velocity  states  is  thus  noted  to  have  a  severe  destabilizing  effect.  Attempts  to 
reduce  this  error  by  increasing  the  observation  processing  rate  to  2  Hz  and  4Hz  (graphs  not 
shown)  did  not  materially  affect  the  results.  The  following  test  case  (1-4)  will  attempt  to  rectify 
this  situation  by  adding  the  three  velocity  error  states  to  the  Kalman  Filter.  The  presence  of  the 
velocity  states  in  closed  loop,  as  described  in  paragraph  4.2. 1.4  ,  will  further  destabilize  the 
solution  by  causing  an  oscillatory  response. 
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4.2.4  Test  Case  1-4  (Closed  Loop)  Effect  of  Unmodeled  Velocity  Errors  (V elocity 
States  Present) 

The  objective  of  this  test  case  was  to  investigate  the  effectiveness  of  adding  the  three 
velocity  states  to  the  Kalman  Filter  model.  This  case  was  identical  to  the  previous  case  except 
for  the  velocity  states.  Three  observation  rates  were  investigated,  namely  1  Hz,  2Hz,  and  4  Hz. 

Initial  Conditions 

Link- 16  Position  Errors  (ERRX,  ERRY  =  2  feet) 

Link- 16  Velocity  Errors  (EVN,EVE  =  1  foot/second) 

Clock  Bias  Error  (50  ns) 

Frequency  Error  (0  ns/sec) 

Velocity  States  -  Present 


Time  (sec)  Time  (sec) 

Figure  4.2-8:  Velocity  states,  IHz  update  rate 


EZ(feel)  EX  (feet)  EZ(feel)  EX  (feet) 
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Height  Error  Clock  Bias 


Time  (sec)  Time  (sec) 

Figure  4.2-9:  Velocity  states,  2Hz  update  rate 


North  Position  Error  East  Position  Error 


Height  Error 


Time  (sec) 


Clock  Bias 


Time  (sec) 


Figure  4.2-10:  Velocity  states,  4Hz  update  rate 
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Analysis  of  Results 

For  all  observation  rates,  the  inclusion  of  the  velocity  states  induces  a  highly  oscillatory 
mode  of  behavior,  with  a  period  of  approximately  17  seconds.  In  the  case  of  the  1  Hz 
observation  rate  (Figure  4.2-8),  the  oscillations  continue  to  increase  in  magnitude  throughout  the 
run.  With  a  2  Hz  update  rate  (Figure  4.2-9),  the  oscillations  damp  out  until  100  seconds,  at 
which  point  a  non-oscillatory  excursion  of  the  state  errors  begins,  leading  to  a  divergent  solution. 
For  the  4  Hz  measurement  rate,  the  oscillations  damp  out  more  quickly,  and  the  errors  appear  to 
be  settling  toward  small  values.  However,  the  errors  diverge,  as  before,  at  approximately  100 
seconds.  The  conclusion  is  that  in  the  presence  of  unmodeled  velocity  errors  during  closed  loop 
operation,  the  solution  cannot  be  stabilized  even  by  increasing  the  measurement  rate.  Based 
upon  Test  Cases  1-1  through  1-4,  the  closed  loop  solution  must  be  considered  unstable  under  all 
conditions.  The  source  of  this  difficulty  lies  in  the  feedback  nature  of  the  correction  process,  in 
which  the  filter  corrections  systematically  correct  the  navigation  error  terms,  at  which  point  they 
are  zeroed.  There  appears  no  simple  or  obvious  way  to  correct  this  problem  without  breaking  the 
solution  feedback  loop.  As  a  result,  we  will  now  consider  the  performance  of  the  algorithm  in 
the  “Open  Loop”  mode,  in  which  the  values  of  the  state  variables  are  maintained  separately  from 
the  Link- 16  navigation  solution,  and  not  zeroed  at  the  time  of  application.  Operationally,  this 
means  that  the  computation  of  the  best  estimates  of  member  position  must  be  computed  outside 
both  the  Navigation  Kalman  Filter  and  the  DGPS  RF  Kalman  filter  by  combining  their  outputs 
without  filter  reset. 


EZ(f0el)  EX  (feet) 
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4.2.5  Test  Case  1-5  (Open  Loop)  Baseline  Test  -  Effect  of  Position  Errors 

The  objective  of  this  test  case  is  to  evaluate  the  performance  of  the  DGPS  RF  algorithm 
working  in  an  Open  Loop  mode,  while  allowing  controlled  variation  of  Link- 16  position  errors 
and  observation  update  rates.  For  this  test  case,  we  set  unmodeled  velocity  errors  to  zero,  and 
delete  the  velocity  states  from  the  Kalman  Filter.  We  are  also  interested  to  determine  the 
practical  limits,  if  any,  on  the  initial  Link- 16  position  errors.  As  the  basic  DGPS  algorithm  is  an 
Extended  Kalman  Filter,  we  expect  that  there  might  be  a  region  of  convergence,  within  which, 
the  errors  will  be  reduced  to  small  values,  but  outside  which,  divergence  results.  As  it  turns  out, 
such  a  limit  does  appear  to  exist  in  the  vicinity  of  760  feet  per  axis  of  position  error. 

Initial  Conditions 

Link- 16  Position  Errors  (ERRX,ERRY  =  2/200/760/765  feet) 

Link- 16  Velocity  Errors  (EVN,  EVE  =  0.0  ft/second) 

Clock  Bias  Error  (50  ns) 

Frequency  Error  (0.0  ns/sec) 

Velocity  States  -  Not  Present 
Measurement  Update  Rate  -  1  Hz 


Height  Error  Clock  Bias 


Time  (sec)  Time  (sec) 

Figure  4.2-11:  Open  loop,  small  position  errors 


EZ(feel)  EX  (test)  EZ(fe6t) 


Application  of  DGPS  to  LI  6  Navigation 


North  Position  Error  East  Position  Error 


Height  Error  Ciock  Bias 


Figure  4.2-12 
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North  Position  Error 


Time  (sec) 


East  Position  Error 


Clock  Bias 


Figure  4.2-14 


Analysis  of  Results 

The  most  significant  result  of  the  switch  to  Open  Loop  operation  is  the  successful 
achievement  of  stable  algorithm  operation  while  driving  the  position  and  clock  bias  errors  to 
extremely  small  levels.  The  simulation  process  was  allowed  to  run  for  2000  seconds  with  no 
sign  of  stability  problems.  Figure  4.2-1 1  (2  Ft  position  errors)  produces  excellent  results  with 
negligible  errors.  Increasing  position  errors  to  200  feet  per  axis  (Figure  4.2-12)  shows  slight 
increases  in  error  levels,  but  still  well  within  acceptable  levels.  The  highest  acceptable  level  of 
position  errors  is  reached  at  760  feet  per  axis  (Figure  4.2-13).  Increasing  the  initial  position 
errors  by  a  small  amount  to  765  feet  per  axis  (Figure  4.2-14)  brings  out  the  first  signs  of  solution 
instability,  with  periodic  spikes  in  error  magnitudes  in  evidence.  The  appearance  of  these  sharp, 
but  short  lived  errors  coincides  with  the  change  of  direction  of  the  participating  platforms  when 
they  execute  their  racetrack  trajectories.  Further  attempts  to  stabilize  the  solution  for  large 
position  errors  by  increasing  the  initial  covariance  and  process  noise  levels  to  2000  feet  were 
unsuccessful.  It  thus  appears  that  these  large  Link-16  position  errors  represent  a  practical  limit 
of  filter  operation.  It  should  be  noted  that  these  position  errors  represent  a  level  far  in  excess  of  a 
stable  Link- 16  solution,  whose  maximum  errors  are  in  the  range  of  50-100  feet.  Also  note  that 
we  do  not  allow  the  DGPS  RF  filter  to  even  begin  operation  until  the  Link- 16  navigation  solution 
has  stabilized  and  converged  to  their  normal  small  steady  state  values. 
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4.2.6  Test  Case  1-6  (Open  Loop)  Effect  of  Observation  Update  Rate 

The  objective  of  this  test  case  is  to  assess  the  effect  of  increased  observation  rate  to  the 
baseline  open  loop  results  discussed  within  the  last  paragraph.  In  addition,  we  wish  to  determine 
if  the  higher  update  rates  can  increase  the  convergence  envelope  for  the  Link- 16  navigation 
errors. 

Initial  Conditions: 

Link-16  Navigation  Position  Errors  (ERRX,  ERRY  =  2  feet,  760  feet) 

Link- 16  Velocity  Errors  (EVN,EVE  =  0.0  ft/sec) 

Clock  Bias  Error  (50  ns) 

Frequency  Error  (0.0  ns/sec) 

Velocity  States  -  Not  Present 


Graphical  Results 
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Figure  4.2-15:  Open  Loop,  2Hz  update  rate 
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North  Position  Error  East  Position  Error 


Height  Error  Ciock  Bias 


Time  (sec)  Time  (sec) 

Figure  4.2-16:  Open  Loop,  4Hz  update  rate 
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Time  (sec)  Time  (sec) 

Figure  4.2-17: 4Hz  update  rate,  760  ft  position  error 
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Analysis  of  Results 

Figure  4.2-15  presents  the  results  of  operating  with  a  2  Hz  update  rate.  The  results  are 
nearly  indistinguishable  from  those  of  the  previous  test  case  because  of  the  scale.  The 
corresponding  result  for  a  4  Hz  update  rate  is  shown  in  Figure  4.2-16,  and  drives  errors  to 
extremely  small  values  with  a  convergence  time  constant  of  1-2  seconds  or  better.  Figure  4.2-17 
maintains  the  4  Hz  update  rate,  but  increases  the  initial  position  error  to  the  critical  level  of  760 
feet.  Once  again,  this  figure  proves  to  be  nearly  the  outer  limit  of  allowable  position  error  for 
system  operation.  The  errors  shown  in  that  figure  are  just  marginal  with  respect  to  the 
performance  goals  of  the  algorithm. 
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4.2.7  Test  Case  1-7  (Open  Loop)  -  Effect  of  Unmodeled  Velocity  Errors 

In  prior  testing  of  the  effect  of  velocity  errors  during  closed  loop  in  paragraphs  4.2.3  and 
4.2.4,  the  destabilizing  effect  of  velocity  errors  was  unmistakable.  This  test  case  reevaluates  the 
results  when  open  loop  operation  is  used.  The  algorithm  performance  under  open  loop 
conditions  indicates  a  remarkable  improvement  as  compared  with  prior  closed  loop  operation. 


Initial  Conditions 

Link- 16  Navigation  Position  Errors  (ERRX,  ERRY  =  730  ft) 
Link- 16  Velocity  Errors  (EVE,  EVN  =1.0  ft/sec) 

Clock  Bias  (50  ns) 

Frequency  Error  (0.0  ns/sec.) 

Velocity  States  -  Both  Included  and  not  included 


Graphical  Results 
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Figure  4.2-18:  Position  errors  =  730  ft,  2Hz  update  rate 
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North  Position  Error  East  Position  Error 


Height  Error  Clock  Bias 


Time  (sec)  Time  (sec) 

Figure  4.2-19:  Position  errors  =  730  ft,  IHz  update  rate 


North  Position  Error  East  Position  Error 
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Figure  4.2-20:  Position  errors  =  730  ft,  4Hz  update  rate 
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Analysis  of  Results 

The  most  significant  results  of  these  runs  is  that,  in  open  loop  operation,  the  presence  or 
absence  of  the  velocity  states  has  no  measurable  effect  on  algorithm  performance.  Stable 
reliable  operation  is  achieved  in  either  case  with  position  errors  as  large  as  730  feet  per  axis,  and 
with  update  rates  of  1  Hz,  2  Hz,  and  4  Hz.  Figure  4.2-18  is  run  at  a  2Hz  update  rate  with 
position  errors  of  730  feet  per  axis.  Figure  4.2-19  is  run  at  an  update  rate  of  1  Hz  and  730  feet 
per  axis,  and  is  only  slightly  worse  than  the  previous  run,  but  still  within  allowable  limits. 
Finally,  Figure  4.2-20  is  run  at  4  Hz,  and  presents  the  smallest  errors  of  all  three  runs. 
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4.2.8  Test  Case  1-8  (Open  Loop)  Effect  of  Clock  Bias  and  Frequency  Drift 

In  this  test  case,  we  concentrate  on  the  performance  of  the  clock  bias  and  frequency 
estimation  in  open  loop  mode.  In  previous  runs,  we  operated  with  a  constant  clock  bias  error  of 
50  ns  and  zero  frequency  drift.  Here,  we  increase  the  clock  bias  initial  error  to  200  ns,  with  a 
frequency  drift  of  10  ns/second.  We  emphasize  that  these  error  values  are  much  larger  than 
would  be  expected  from  the  normal  operation  of  a  GPS  receiver.  However,  the  ability  to  rapidly 
and  effectively  calibrate  these  errors  has  great  value  if  the  DGPS  community  is  called  upon  to 
function  as  a  time  transfer  agent,  using  external  time  references  to  drive  the  GPS  receiver 
element. 


Initial  Conditions 

Link- 16  Position  Errors  -  (ERRX,  ERRY  =  200  feet) 
Link-16  Velocity  Errors  -  (EVN,EVE  =  1  ft/Sec.) 
Clock  Bias  Error  -  (200  ns) 

Frequency  Error  -  (10  ns/sec) 

Observation  Rate:  1  Hz 


Application  of  DGPS  to  LI  6  Navigation 


Page  72 


Graphical  Results 
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Figure  4.2-21:  Clock  Bias  /  Frequency  Error  Estimation 


Analysis  of  Results 

As  noted  in  Figure  4.2-21,  the  algorithm  is  demonstrated  to  operate  effectively  and  stably 
even  with  large  offsets  in  both  time  and  frequency.  Excellent  performance  is  noted  for  all  three 
position  terms  as  well  as  clock  bias  and  frequency  drift.  Frequency  drift,  in  particular  is 
observed  to  reflect  the  same  time  constant  as  all  other  states  when  1  Hz  observation  rate  is  used. 
In  other  runs,  not  shown  here,  the  same  conclusion  is  reached  when  update  rates  are  increased  to 
2  Hz  and  4  Hz.  In  the  latter  case,  frequency  drift  is  estimated  within  1-2  seconds  of  filter 
operation.  These  results  are  unaffected  whether  or  not  the  velocity  states  are  included  within  the 
model. 
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4.2.9  Test  Case  1-9  (Open  Loop)  Effect  of  Process  Noise  on  Solution 

The  quantity  of  measurement  information  available  from  the  multiple  satellites  tends  to 
drive  down  the  level  of  the  RF  covariance  matrix.  The  purpose  of  this  test  case  is  to  optimize  the 
level  of  process  noise  to  be  applied  to  the  RF  Kalman  Filter  position  states. 

Initial  Conditions 

Link- 16  Navigation  Position  Errors  (ERRX,ERRY  =  2  feet) 

Velocity  Errors  (EVN,EVE  =  0.0  ft/sec) 

Clock  Bias  Error  (50  ns) 

Frequency  Error  (0.0  ns/sec) 

Measurement  Rate  (4  Hz) 

Graphical  Results 


0.2  ft  process  noise 


1.0  ft  process  noise 


10.0  ft  process  noise 


Figure  4.2-22:  Process  Noise  Tradeoffs 
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Analysis  of  Results 

The  results  summarized  in  Figure  4.2-  22  provide  clear  evidence  of  the  need  for  high 
levels  of  process  noise  to  be  applied  to  the  RF  Kalman  Filter.  The  position  estimation 
performance  when  process  noise  of  10.0  feet  per  axis  is  noticeably  better  than  that  at  higher 
values.  This  figure  appears  to  be  the  lowest  level  of  process  noise  that  provides  good 
performance.  Addition  of  still  higher  values  provides  no  additional  benefit  to  position  estimation 
performance. 
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4.2.10  Test  Bed  1  Operation  -  Summary  and  Conclusions 

The  eight  preceding  test  cases  summarize  the  simulation  activity  and  results  obtained 
using  Test  Bed  1.  The  primary  goal  of  this  simple  but  versatile  tool  was  to  provide  a  capability 
for  isolating  the  effect  on  algorithm  performance  of  individual  error  terms  under  carefully 
controlled  conditions.  The  most  significant  conclusion  of  this  portion  of  the  study  is  that  the 
closed  loop  operation  always  results  in  unstable  operation,  even  though  the  instability  may  take  a 
long  time  of  operation  to  make  itself  evident.  Another  important  conclusion  is  that  the  use  of  the 
three  velocity  states  is  ineffective,  causing  oscillatory  behavior  in  closed  loop  operation,  and  not 
preventing  divergence  in  any  application.  In  open  loop  operation,  the  velocity  states  have 
virtually  no  effect  at  all,  for  better  or  for  worse.  Yet  another  important  conclusion  is  that  an  error 
limit  of  about  760  feet/axis  has  been  identified  for  the  magnitude  of  the  Link- 16  navigation 
error.  The  bad  news  is  that  this  limit  exists  at  all;  the  good  news  is  that  it  far  exceeds  normal 
operation  of  Link- 16,  and  should  not  present  any  operational  issues. 

The  open  loop  operation  of  the  algorithm  has  proven  to  produce  stable  and  reliable 
operation  that  is  virtually  insensitive  to  the  magnitude  of  errors  as  long  as  the  initial  covariance 
and  process  noise  is  sufficient  to  cover  these  errors.  (Exception  -  LI 6  position  error,  as  already 
noted).  The  basic  health  of  the  algorithm  depends  on  maintaining  the  level  of  the  covariance  via 
process  noise  modeling,  because  of  the  excess  of  information  provided  by  up  to  10-1 1  satellites 
per  observation  cycle.  We  do  not  wish  to  allow  the  covariance  matrix  to  be  anything  other  than 
positive  definite. 

The  promising  performance  of  the  DGPS  algorithm  is  welcome  and  reassuring,  but  we 
note  that  the  error  profiles  provided  by  the  Link- 16  navigation  in  Test  Bed  1  were  simplistic  and 
not  necessarily  representative  of  the  actual  navigation  and  bias  errors  experienced  with  a  real 
Link- 16  community.  The  purpose  of  Test  Bed  2,  built  around  the  reliable  Link- 16  Navigation 
Simulator,  is  to  provide  a  realistic  navigation  environment  for  the  DGPS  algorithm.  That  study 
is  presented  in  the  following  paragraph,  4.3. 
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4.3  Test  Bed  2  Simulation  Activities 

Overview  and  Rationale 


The  analysis  and  simulation  described  in  paragraph  4.2  using  Test  Bed  1  was  designed  to 
determine  the  fundamental  performance  limitations  and  sensitivities  of  the  DGPS  RF  algorithm 
under  carefully  controlled  conditions.  It  was  well  understood  that  the  test  conditions,  such  as 
the  Link- 16  constant  error  profile  were,  to  some  extent,  artificial  and  did  not  truly  reflect  the 
actual  error  dynamics  of  a  realistic  Link- 16  mobile  community.  These  dynamics  can  only  be 
represented  by  replacing  the  covariance  approximation  of  the  COV50  software  with  the  Link-16 
Navigation  Simulator  (LNS)  as  a  driver  of  the  DGPS  RF  algorithm. 

The  LNS  is  a  proprietary  computer  program  developed  by  BAE  SYSTEMS  which 
embodies  the  actual  operational  navigation  code  executing  on  each  and  every  Link- 16  terminal. 
Under  development  for  nearly  thirty  years,  the  LNS  has  become  a  trusted  surrogate  which 
accurately  represents  Link- 16  navigation  performance  under  all  operational  conditions.  The 
combination  of  the  LNS  and  the  DGPS  RF  source  code  plus  a  circular  GPS  satellite  routine 
constimtes  Test  Bed  2,  which  will  be  used  in  all  further  simulations  presented  within  this  study. 
The  LNS  permits  the  navigation  design  engineer  to  analyze  both  community  and  individual 
platform  performance  in  the  areas  of  Navigation,  Time  Synchronization,  and  (in  special  versions) 
Sensor  Registration.  The  LNS  is  written  in  VAX  Fortran  77,  and  comprises  45  source  code 
modules  which  are  always  configured  to  replicate  exactly  the  terminal  operational  code.  (Figure 
4.3-1)  Thus,  no  approximations  or  assumptions  need  be  made  in  interpreting  navigation 
performance;  it  faithfully  represents  the  performance  that  a  real  terminal  would  deliver  under 
simulation  conditions  and  trajectories.  A  full  description  of  the  structure  and  organization  of 
the  LNS  is  presented  in  Appendix  B. 
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Sequence  Applies 
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L  -  _  j  Module 


Figure  4.3-1:  LNS  Architecture 


Based  upon  the  studies  documented  using  Test  Bed  1,  all  runs  executed  herein  will  only 
operate  using  the  Open  Loop  mode,  since  closed  loop  operation  has  been  determined  to  be 
unstable.  A  firm  ground  rule  has  been  established  for  these  simulations,  as  follows.  The  DGPS 
RF  algorithm  will  not  be  permitted  to  begin  its  execution  unless  and  until  the  Link- 16  navigation 
performance,  as  constructed  by  the  LNS,  has  been  allowed  to  reach  steady  state  operation.  This 
rule  will  be  adapted  for  any  further  laboratory  and  /or  flight  test  activity  of  the  DGPS  RF 
algorithm.  The  quality  of  the  Link- 16  navigation  performance  will  be  varied  considerably 
during  the  Test  Bed  2  simulations,  always  keeping  in  mind  that  earlier  Test  Bed  1  simulation  has 
uncovered  regions  within  the  space  of  position  errors  which  may  lead  to  instability.  Even  in  the 
test  cases  where  larger  than  normal  Link- 16  position  and  velocity  errors  are  imposed,  these 
errors  will  never  be  larger  than  50%  of  the  limiting  position  errors  (760  fl/axis) 


I 
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Community  Navigation  Trajectory  and  Error  Budgets 

The  trajectories  of  the  two  participating  platforms  are  as  they  were  presented  in  Figure 
4.2-3.  The  nature  of  the  Link-16  navigation  errors  of  the  two  platforms  are  functions  of  many 
variables,  including  the  error  budgets  of  their  included  inertial  platforms,  the  presence  or  absence 
of  GPS  PVT  processing,  and  the  PPLI  transmission  rate  between  master  and  slave  platforms. 
Table  4.3-1,  below,  lists  the  critical  navigation  error  budgets  of  the  participants,  as  well  as  the 
DGPS  RF  Kalman  Filter  tuning  constants. 

The  navigation  error  budgets  of  the  mobile  members  are  characteristic  of  the  high  quality 
inertial  navigation  units  typically  installed  on  modem  military  fighter  aircraft.  In  the  case  of 
Link- 16,  terminals  are  designed  to  accept  position,  and  time  (PVT)  updates  from  installed  GPS 
units,  if  available.  Position  updates  are  usually  scaled  to  represent  10  meters  CEP  position 
quality,  while  time  updates  are  assumed  to  be  accurate  to  50  ns  RMS  error.  These  error  budgets 
,assigned  to  the  mobile  members  shall  be  considered  the  Nominal  navigation  error  budgets. 

The  DGPS  RF  Kalman  Filter  error  parameters  are  also  listed  in  Table  4.3-1,  and  represent 
the  Nominal  values  assigned  to  this  algorithm.  In  the  simulation  studies  listed  herein,  these 
nominal  values  for  both  navigation  and  DGPS  RF  shall  be  used,  except  for  special  cases,  as 
noted,  where  study  requirements  require  variations  in  these  terms. 
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BZ_G 

1.3e-3  [deg/hr] 

SFX  G 

-4.1e-2  [percent] 

Gyro  scale  factor 

SFY_G 

3.2e“2  [percent] 

SFZ_G 

4.4e-2  [percent] 

XZ  G 

32.0  [arcsec] 

XY  G 

19.0  [arcsec] 

YZ  G 

17.0  [arcsec] 

Gyro  non-orthogonalities 

YX  G 

-71.0  [arcsec] 

ZY  G 

-10.0  [arcsec] 

ZX_G 

63.0  [arcsec] 

MUX  G 

-0.023  [deg/hr/g] 

Gryo  mass  unbalance 

MUY  G 

-0.076  [deg/hr/g] 

MUZ_G 

0.023  [deg/hr/g] 

ANX  G 

0 . 004  [deg/hr/g**2] 

Gyro  anisoelasticity 

ANY__G 

0.002  [deg/hr/g**2] 

ANZ_G 

0 . 001  [deg/hr/g**2] 

GEO  POS  UNC 

1006.0  [feet] 

ALT  BIAS  UNC 

405.6  [feet] 

Initial  values  for  geodetic  state 

AZIM_UNC 

0.5  [degrees] 

covariances 

VEL_UNC 

7.5  [ft/sec] 

TILT  UNC 

0.0417  [degrees] 

ALT_SF_UNC 

3.0  [percent] 

Initial  values  for  geodetic  state 

process  noise  values .  (NICP  standard 

values) 

(NICP  =0.12  [ft**2/sec] ) 

GEO_POS_PN 

0.12  [ft**2/sec] 

(NICP  =0.25  [ft**2/sec] ) 

ALT__BIAS_PN 

0.25  [ft**2/sec] 

(NICP  =l.D-4) 

ALT_SF_PN 

l.D-4 

F/A-18-RLG  Values 

8.965D-14 

[rad**2/sec] 

(NICP  =  2.597D-13  [rad**2/sec] ) 

AZIM_PN 

7 . 914D-5 

(NICP  =  1.648D-4  [ft**2/sec**3] ) 

VEL_PN 

[ft**2/sec**3] 

(NICP  =  2.467D-13  [rad**2/sec] ) 

TILT_PN 

8 .954D-14 

[rad**2/sec] 

PPLI  measurement  noise  value 

PPLI__MEAS_NOISE 

400  [ns**2] 

Covariance  Matrix 

North  Position  Covariance 

PA  (1,1) 

1000000.0 

West  Position  Covariance 

PA (3, 3) 

1000000.0 

Altitude  Covariance 

PA (5, 5) 

1000000.0 

Clock  Bias  Covariance 

PA  (7, 7) 

10000.0 

Freq.  Drift  Covariance 

PA (8, 8) 

100.0 

Process  Noise  Covariance  Matrix 
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North  Position  Process  Noise 

West  Position  Process  Noise 

Altitude  Process  Noise 

Clock  Bias  Process  Noise 

Freq.  Drift  Process  Noise 

QA(1,1) 

QA(3,3) 

QA(5,5) 

QA(7,7) 

QA(8,8) 

1000000.0 

1000000.0 

1000000.0 

100.0 

1.0 

Observation  Noise  Covariance  Matrix 

RA(1,1) 

441.0 

RA(2,2) 

156.25 

RA(I,I)  for 

16.0 

1=3,12 

Table  4.3-1:  Navigation  Error  Budgets 
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Preview  of  Test  Bed  2  Simulation  Results 

The  DGPS  RF  algorithm  architecture  and  tuning  constants  developed  in  paragraph  4.2  were 
evaluated  in  Test  Bed  2  with  the  full  Link- 16  community  navigation  error  model  provided  by  the 
LNS  code.  A  full  range  of  parameter  variations  were  applied,  including  observation  update  rate, 
number  of  processed  GPS  satellites,  and  quality  of  the  Link- 16  navigation  solution.  In  all  cases, 
the  DGPS  algorithm  provided  a  robust,  and  accurate  estimate  of  position  and  clock  errors  for  the 
mobile  community.  Highlights  of  the  most  significant  results  are  summarized  below: 

(a)  Good  to  excellent  performance  was  produced  using  variable  observation  update  rate 
covering  the  range  4  Hz,  2Hz,  IHz,  0.25Hz.  Although  some  dilution  of  performance 
is  noted  for  the  lowest  of  these  rates,  the  application  of  low  pass  filtering  of  the  error 
terms  shows  beneficial  results. 

(b)  Sensitivity  of  the  DGPS  estimation  error  with  respect  to  raw  Link- 16  navigation 
errors  appears  to  be  extremely  low.  Use  of  degraded  INS  navigation  models  causes 
large  increases  in  raw  platform  navigation  error,  but  minimal  effect  on  the 
performance  of  the  DGPS  RF  algorithm. 

(c)  In  the  event  of  partial  jamming  of  the  GPS  constellation,  the  performance  level  of  the 
DGPS  algorithm  could  be  significantly  affected.  Simulation  shows  virtually  no 
degradation  of  performance  with  as  few  as  six  visible  satellites,  although  total 
collapse  of  the  solution  is  noted  when  the  number  of  processed  satellites  is  reduced  to 
four. 

(d)  The  Link- 16  Kalman  Filter  position  update  processing  causes  discontinuities  in  raw 
position  error,  resulting  in  much  smaller  discontinuities  in  the  DGPS  RF  error  results. 
The  DGPS  RF  discontinuities  coincide  with  Link- 16  position  updates,  but  disappear 
within  one  observation  cycle  thereafter.  Even  these  small  variations  can  be  reduced 
by  introduction  of  simple  low  pass  filtering  on  the  DGPS  results 

Full  discussion  of  all  of  the  above  conclusions  is  provided  in  the  analyses  of  each  of  the  test 
cases  which  constituted  this  portion  of  the  study. 
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4.3.1  Test  Case  (2-1)  Performance  Sensitivity  to  Observation  Update  Rate 

This  series  of  simulations  is  designed  to  evaluate  DGPS  RF  performance  against  the 
realistic  LNS  Link- 16  navigation  error  model,  while  varying  the  basic  pseudorange  update  rate 
over  the  range  4  Hz,  2  Hz,  IHz,  and  0.25Hz.  Unlike  the  simulations  performed  within  the  Test 
Bed  1  software  where  navigation  position  and  velocity  errors  were  constant,  the  position  and 
velocity  errors  of  the  two  platform  configuration  present  a  dynamic  variation.  This  dynamic 
error  profile  is  the  resultant  of  the  inertial  error  budgets  of  the  two  platforms,  their  trajectories, 
and  the  measurements  processed  by  the  Link- 16  Navigation  Kalman  filter.  The  observation 
processing  utilized  for  Link- 16  navigation  is  precisely  that  utilized  in  normal  terminal  operation, 
that  is  PPLI  measurements  transmitted  from  master  to  slave  at  a  12  second  rate,  plus  GPS  PVT 
measurements  incorporated  at  an  identical  12  second  rate.  No  feedback  or  adjustment  of  this 
hybrid  inertial  solution  from  the  DGPS  RF  is  implemented.  The  Link- 16  navigation  algorithm  is 
completely  untouched. 

In  Equation  (4),  we  defined  the  DGPS  RF  observation  matrix  H  to  accept  PPLI 
measurements,  as  well  as  GPS  pseudorange  measurements.  These  measurements,  at  a  rate  of 
one  per  12  seconds  were  incorporated  in  the  simulations  performed  as  part  of  Test  Bed  1.  No 
attempt  was  made  in  that  study  to  evaluate  the  effectiveness  of  these  observations,  as  compared 
with  the  GPS  pseudorange  measurements.  That  evaluation  was  conducted  as  part  of  Test  Bed  2 
operation,  however.  The  result  of  that  analysis  was  the  unsurprising  conclusion  that  when 
measured  against  the  information  content  of  8-12  satellite  pseudoranges,  the  PPLI  range 
measurements  had  no  measurable  effect  on  the  RF  solution.  The  results  presented  in  this 
section  of  the  report  therefore  deleted  the  use  of  PPLI  range  measurements  by  the  DGPS  RF 
Kalman  Filter,  and  relied  exclusively  on  pseudorange  measurements.  There  are  conceivable 
circumstances,  such  as  partial  jamming  of  the  GPS  satellite  constellation,  where  it  may  pay  to 
revisit  the  use  of  these  range  measurements.  This  point  is  further  discussed  in  paragraph  4.3.X. 


Test  Conditions 

Link- 16  Navigation  Error  Budget:/  Measurement  Schedule  -  Nominal 

DGPS  Configuration  -  Nominal 

Psuedorange  Update  Rates:  4Hz,  2Hz,  IHz,  0.25Hz 


Error  (feel)  Error  (feet) 
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Figure  4.3-2:  Test  Bed  2  DGPS  Performance  -  4Hz  update  rate 
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Figure  4.3-3:  2Hz  update  rate 
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Figure  4.3-4:  IHz  update  rate 
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Figure  4.3-5:  0.25Hz  update  rate 
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Analysis  of  Results 

Figure  4.3-2  presents  the  RF  position  errors  developed  during  a  test  for  which  the 
pseudorange  observation  update  rate  is  4  Hz.  In  this  figure  (upper  three  curves),  the  relative 
navigation  position  error  of  the  two  mobile  members  using  nominal  error  budgets  is  displayed  in 
red.  The  trend  of  this  position  error  is  nearly  sinusoidal  in  nature,  with  an  average  error  per 
horizontal  axis  of  approximately  40-50  feet.  The  jagged  breaks  in  the  position  error  terms  are 
caused  by  the  GPS  12  second  measurement  updates,  which  create  step  changes  in  these  position 
error  terms.  The  corresponding  DGPS  RF  errors  in  estimating  these  relative  navigation  error 
terms  appear  in  blue,  and  appear  “spiky”  in  nature.  Note  that  the  appearance  of  these  spikes 
coincide  with  step  changes  in  the  relative  position  error  of  the  navigation  solution.  The  spike 
duration  is  no  more  than  the  0.25  second  DGPS  RF  Kalman  Filter  cycle  time,  at  which  point, 
each  error  collapses  nearly  to  zero.  The  sense  (positive  or  negative)  of  each  spike  is  of  the 
opposite  sign  to  that  of  the  corresponding  navigation  error.  Both  the  appearance  and  the 
characteristics  of  the  spikes  are  explained  by  the  fact  that  there  is  no  direct  connection  between 
the  L16  navigation  position  updates  and  that  of  the  DGPS  filter.  Any  step  change  in  the  former 
must,  by  definition,  cause  a  step  change  in  the  latter  error  source.  Please  note  that  the  short 
duration  of  these  spikes  is  caused  by  the  fact  that  multiple  satellite  pseudorange  measurements 
become  available  to  the  DGPS  filter  immediately  after  the  step  change  occurs,  and  these  spikes 
are  nearly  perfectly  negated  by  further  measurements.  Thus,  there  is  virtually  no  “steady  state” 
DGPS  error,  which  averages  near  zero  over  time  with  the  exception  of  those  instants  where  the 
reference  solution  changes  sharply.  This  fact  is  borne  out  by  the  lower  three  graphs,  which 
rescale  the  DGPS  errors  to  make  them  easier  to  see,  A  little  consideration  indicates  that  the 
“true”  relative  position  error  between  the  mobile  members,  as  opposed  to  that  estimated  by  the 
Navigation  Kalman  Filter,  must  be  a  smoothly  varying  function  of  time.  Since  the  user  of  this 
precision  navigation  would  prefer  a  smoothly  varying  function,  we  will  later  process  the  DGPS 
output  data  through  a  low  pass  filter  to  smooth  the  spiky  error  profile  and  more  closely  reflect 
the  true  error  characteristics.  Please  refer  to  Paragraph  4.3.2  for  details  of  this  computation  and 
results. 


In  Figure  4.3-3,  we  decrease  the  pseudorange  observation  rate  to  2  Hz,  and  interpret  the 
results  exactly  as  for  Figure  4.3-2.  A  comparison  of  the  2  Hz  results  with  the  4  Hz  results  shows 
virtually  no  difference  between  the  two  charts.  The  1  Hz  results,  given  in  Figure  4.3-4  still  show 
little  change  from  the  4Hz  case.  It  is  only  when  we  decrease  the  update  rate  to  one  per  four 
seconds  (Figure  4.3-5),  that  a  slight  degradation  of  results  appears.  In  general,  for  all  four 
simulations,  it  is  noted  that  the  vertical  channel,  eZ,  produces  errors  of  a  larger  magnitude  then 
those  of  the  horizontal  axes.  This  can  be  explained  by  the  fact  that  most  of  the  satellites  used  are 
relatively  low  on  the  horizon,  and  thus  provide  less  information  along  the  vertical  axis. 

Because  of  the  time  scale  of  these  results,  the  transient  performance  of  the  DGPS  is  not 
visible  on  any  of  the  four  graphs,  which  illustrate  steady  state  performance  only.  Since  there  is 
essentially  no  steady  state  performance  advantage  between  the  observation  rates  of  1, 2,  and  4 
Hz,  we  would  presumably  seek  the  lowest  rate  for  operational  use  of  this  technology  provided 
there  were  no  pressing  reason  to  insist  on  filter  convergence  within  a  few  seconds.  Even  for  the 
1  Hz  rate,  this  convergence  occurs  within  no  more  than  50-60  seconds.  We  shall  further  discuss 
the  optimal  choice  of  DGPS  Kalman  Filter  cycle  time  in  paragraph  5.0. 
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4.3.2  Test  Case  (2-2)  Performance  Sensitivity  to  Low  Pass  Filtering  of  DGPS  RF 
Error  Terms 

In  the  previous  paragraph,  the  discontinuities  of  the  Link- 16  hybrid  navigation  solution 
were  noted  to  produce  spiky  discontinuities  of  the  DGPS  estimation  error  terms.  We  now 
investigate  the  effect  of  applying  a  low  pass  first  order  digital  filter  to  these  error  terms  in  an 
attempt  to  smooth  out  these  discontinuities  and  more  accurately  represent  the  steady  state 
performance  of  the  filter.  In  this  series  of  tests,  we  repeat  the  runs  performed  in  4.3.1  with 
Kalman  Filter  cycles  of  4, 2,  and  1  Hz  with  a  low  pass  filter  time  constant  of  1  second. 


Test  Conditions 

Link- 16  Navigation  Error  Budget:/ Measurement  Schedule  -  Nominal 
DGPS  Configuration  -  Nominal 
Psuedorange  Update  Rates:  4Hz,  2Hz,  IHz 


Error  (feet)  Error  (feet) 
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Graphical  Results 
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Figure  4.3-6:  Low  pass  Altering  ~  4Hz 
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Figure  4.3-7:  Low  pass  Hltering  -  2Hz 
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Figure  4.3-8:  Low  pass  filtering  -  IHz 
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Analysis  of  Results 

The  application  of  a  low  pass  digital  filter  with  time  constant  tau  of  1  second  to  the  DGPS  error 
quantities  brings  the  steady  state  error  of  each  of  the  position  states  down  to  well  under  the 
desired  one  meter  for  each  of  the  observation  rates  tested.  The  meaning  of  the  discontinuities 
that  were  removed,  however,  is  not  that  the  DGPS  filter  estimates  themselves  were  spiky,  but  in 
fact,  the  hybrid  navigation  solution  itself.  Therefore,  an  important  lesson  to  keep  in  mind  when 
we  wish  to  combine  the  results  of  the  Link- 16  navigation  and  the  DGPS  is  not  to  add  the  DGPS 
corrections  to  the  L16  hybrid  solution  itself,  but  to  a  low  pass  filtered  version  of  the  Link- 16 
hybrid  navigation  solution. 

In  conventional  usage  of  the  Link- 16  hybrid  navigation  solution,  the  step  changes  due  to  Kalman 
corrections  are  normally  too  small  to  worry  about.  In  precision  navigation,  however,  these  step 
changes  are  large  compared  to  the  desired  performance  levels,  and  must  be  treated  as  stated 
above.  We  shall  return  to  this  important  distinction  in  the  conclusions  discussed  in  Paragraph 
5.0. 
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4J.3  Test  Case  (2-3)  Performance  Sensitivity  to  Link-16  Navigation  Position  and 
Velocity  Errors 

In  paragraphs  4.2.3  and  4.2.5,  we  examined  the  effect  of  unmodelled  Link-16  velocity 
and  position  errors  on  DGPS  RF  performance.  We  return  to  this  study  using  Test  Bed  2  by 
imposing  larger  than  normal  Link- 16  navigation  dynamic  position  and  velocity  errors.  We 
achieve  these  errors  by  derating  the  IMU  model  to  provide  a  level  of  performance  which  is  worse 
than  would  normally  be  tolerated  on  a  modem  high  performance  fighter  aircraft.  Specifically, 
we  have  chosen  to  increase  the  gyro  drift  terms  (constant  portion  of  gyro  drift  rate)  by  an  order 
of  magnitude.  As  will  be  noted  below,  this  will  have  an  effect  of  nearly  doubling  the  magnitude 
of  the  position  and  velocity  terms  of  the  relative  Link- 16  navigation  solution  over  that  provided 
by  a  nominal  error  budget,  as  shown  in  the  previous  two  paragraphs.  While  these  position  errors 
exceed  125  feet  per  horizontal  axis,  they  remain  well  below  our  computed  limit  of  approximately 
760  feet  per  axis  for  DGPS  operation.  As  will  be  noted  below,  a  minimal  degradation  in  DGPS 
RF  performance  will  result,  which,  in  turn,  can  be  well  damped  via  use  of  the  low  pass  filtering 
technique  introduced  in  4.3.2. 


Test  Conditions 


Link- 16  Navigation  Error  Budget:/  Measurement  Schedule  -  Nominal,  except  for 
Gyro  drift  bias  terms  increased  to: 

BX_G  =  1.5E-2  [degrees/hr] 

BY_G  =  6.8E-2  [degrees/hr] 

BZ_G=  1.3E-2  [degrees/hr] 


DGPS  Configuration  -  Nominal 
Pseudorange  Update  Rate  IHz 
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Time  (sec) 


Figure  4.3-9:  Sensitivity  to  large  L16  navigation  errors 


Analysis  of  Results 


As  is  clearly  indicated  in  Figure  4.3-9,  the  Link- 16  relative  navigation  solution  has  been 
severely  impacted  by  the  increase  in  gyro  bias  of  the  respective  inertial  measurement  units,  with 
position  swings  nearly  tripling  to  the  130  feet/  axis.  By  comparison,  the  degradation  of  the 
DGPS  RF  solution  is  restricted  to  increases  in  the  spikes  of  less  than  12  feet.  As  was  the  case  in 
the  previous  section,  the  addition  of  low  pass  filtering  can  easily  reduce  these  to  acceptable 
values.  We  thus  have  demonstrated  that  the  DGPS  RF  algorithm  can  easily  accommodate  much 
poorer  than  nominal  platform  navigation  performance,  and  still  recover  the  majority  of  these 
errors. 
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4  J.4  Test  Case  (2-4)  Sensitivity  to  Number  of  Satellites  Processed 

Although  the  DGPS  RF  algorithm  will  normally  attempt  to  process  as  many  satellites  as 
are  visible  and  above  5  degrees  elevation,  one  can  conceive  of  hostile  jamming  situations  where 
some  percentage  of  these  satellites  are  not  usable.  It  is  therefore  useful  to  study  the  performance 
of  the  DGPS  RF  algorithm  where  the  number  of  satellites  processed  per  update  period  is 
restricted  to  less  than  the  normal  10-12  number.  In  this  test  case,  we  have  capped  the  number  of 
processed  satellites  over  the  range  {  8,6,5,  and  4}  to  investigate  the  performance 
of  the  DGPS  RF  filter. 

Test  Conditions 

Link-16  Navigation  Error  Budget:/ Measurement  Schedule  -  Nominal 
DGPS  Configuration  -  Nominal 
Psuedorange  Update  Rates:  IHz 
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Figure  4.3-10:  8  satellite  constellation 
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Figure  4.3-11:  6  satellite  constellation 
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Figure  4.3-12:  5  satellite  constellation 


- - 1 - 1 - i  1 

III) 

1  1  1  1 

1  1  1  1 

1  1  1  t 

1  1  1  i  / 

'll! 

~  —  RF  Errors 
- Nav  Errors 

— f - 

- 

1  1  1  )  > 
III)' 

_ I _ 1 _ I - ^ ^ - 

.p  L _ I - 1 - 1 - ' - ' - ' 

o  500  1 000  1 500  2000  2500  3000 


Time  (sec) 


Figure  4.3-13:  4  satellite  constellation 
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Analysis  of  Results 

Figure  4.3-10  illustrates  the  performance  of  the  DGPS  RF  filter  when  only  8  satellites  are 
processed  per  update  cycle.  Virtually  no  difference  is  noted  between  these  results  and  that 
shown  in  Figure  4.3-4,  where  10  satellites  are  processed.  Further  reducing  the  number  of 
satellites  to  6,  as  shown  in  Figure  4.3-1 1  shows  only  slightly  higher  spike  errors  as  compared 
with  the  previous  case.  Restricting  the  number  of  satellites  observed  to  5,  as  shown  in  Figure 
4.3-12,  shows  somewhat  greater  degradation,  but  these  errors  can  be  easily  smoothed  by  low 
pass  filtering,  as  was  discussed  in  paragraph  4.3.2.  It  is  only  when  the  number  of  processed 
satellites  decreases  to  4,  which  is  the  bare  minimum  for  normal  GPS  PVT  solutions,  that  the 
DGPS  RF  filter  solution  collapses  completely.  We  can  therefore  conclude  that  the  DGPS  RF 
algorithm  is  highly  robust  with  respect  to  the  number  of  satellites  processed.  An  additional 
observation  is  that  the  largest  effect  of  a  reduction  in  satellites  processed  is  observed  in  the 
vertical  axis.  We  note,  however,  that  this  axis  usually  showed  the  largest  errors,  due  to  the  fact 
that  most  of  the  processed  satellites  are  relatively  low  on  the  horizon,  and  thus  provide  less 
information  for  the  vertical  axis 
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4.3.5  Test  Case  (2-5)  Sensitivity  to  Clock  Bias  and  Frequency  Errors 

The  objective  of  this  test  case  is  to  revisit  the  DGPS  RF  solution  sensitivity  to  large  clock 
bias  and  frequency  errors,  a  case  that  was  first  studied  in  Test  Bed  1 ,  Paragraph  4.2.8.  In  the 
former  case,  the  Link- 16  position  errors  were  essentially  constants,  whereas  in  this  test  case,  the 
full  dynamic  navigation  error  model  has  been  applied.  We  again  consider  large  clock  bias  and 
frequency  errors  ,namely  200  ns  of  GPS  receiver  bias,  coupled  with  a  10  ns/seconds  frequency 
drift  term.  We  again  note  that  these  are  very  large  values  unlikely  to  occur  in  modem  GPS 
receiver  units. 

Test  Conditions 

Link- 16  Navigation  Error  Budget:/ Measurement  Schedule  -  Nominal 

DGPS  Configuration  -  Nominal 

Pseudorange  Update  Rate:  4  Hz 

GPS  Clock  Bias:  200  ns 

GPS  Frequency  Drift:  10  ns/sec 
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Graphical  Results 
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Figure  4,3-14:  Test  Bed  2  -  clock  bias/frequency  error  performance 
Analysis  of  Results 

The  successful  estimation  by  the  DGPS  RF  algorithm  of  these  large  clock  bias  and 
frequency  terms  noted  in  Paragraph  4.2.8  is  replicated  here  as  well.  The  performance  levels  of 
the  three  position  states  is  equivalent  to  earlier  Test  Bed  2  results,  while  the  Clock  Bias  (Be)  and 
Frequency  (fc)  results  are  likewise  stable  and  well  behaved.  In  short,  the  filter  has  been 
demonstrated  to  produce  robust  performance  even  in  the  case  of  severe  clock  bias  and  frequency 
offsets.  In  other  runs,  not  reproduced  here,  equivalent  performance  was  demonstrated  even  at 
slower  update  rates  of  1  and  2Hz,  at  the  expense  of  a  slightly  slower  filter  convergence  rate. 
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4.4  DGPS  RF  Operational  Software  Design 

This  section  provides  an  overview  of  the  software  implementation  of  the  DGPS  RF 
algorithm  as  an  extended  version  of  the  existing  Link- 16  operational  computer  program  (LI  6 
CXUP).  The  core  processing  of  the  DGPS  RF  interfaces  with  the  L16  OCP  and  the  host.  The  L16 
OCP  provides  critical  self-navigation  data  derived  from  the  organic  navigation  algorithm  of  LI  6. 
Also  provided  by  the  LI  6  OCP  are  received  Master  Message  data.  The  host  provides  GPS 
ephemeris  data,  GPS  pseudorange  data,  and  control  data.  Figure  4.4-1  illustrates  the  DGPS 
interface  elements.  All  algorithm  inputs  and  outputs  are  presented,  respectively,  in  Tables  4.4-1 
and  4.4-2. 


Pilot  GPS 

it 

_ MMS  (2,  3,  4) _ ^ 

MASTER.MSG  (2,  3,  4)  ^ 


MS_IND  (2.  3,  4) 


EST_SNAV  (2,  3,  4) 


SNAV_VAL_IND  (2,  3,  4) 


RF_OPR_SW  (2.  3,  4) 


SELF_GPS_DATA  (2,  3,  4) 


MS_IND  (2,  3,  4) 


RF.ENABLE  (2.  3,  4) 


LINK-16 

OCP 


TRUE_SNAV(1,2) 


TRUE_MNAV(1,2) 


TRUE_CL0CK_BIAS  (1,2) 


TRUE_FREQ_DRIFT  (1,2) 


PPLI.DATA  (4) 


RTT.DATA  (4) 


CSCI_VERSION(I,2,  3,4) 


DGPSRF 

CORE 


GPS_VAL_IND  (2,  3,  4) 


EPHEM.DATA  (2,  3,  4) 


MASTER_MSG  (2,  3,  4) 


RF_HEALTH_STATUS_MSG 

(1.2,3,^ 


RF_RESULTS_DATA  (4) 


Because  for  the  differing  data  requirements  of  the  four  software  versions,  certain  operation  of  data 
paths  will  be  represented  as  a  function  of  the  CSCI  Version  indicator.  These  paths  are  labeled  as  to 
version  usage  via  a  subset  of  the  integers  (1,  2,  3, 4),  where  each  number  designates  the  version(s) 
that  data  element  will  be  required. 


Figure  4.4-1;  DGPS  Interface  Elements 
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Inputs 

Version 

Definition 

Description 

MMS 

2,3,4 

Master  Message  Signal  - 
indicates  master  message  is 
present  and  valid 

MASTER_MSG 

2,3,4 

MNAVTOV,  MLAT,  MLON, 
MALT,  MEVEL,  MNVEL, 
MALTR,  GPS_HEALTH_IND, 
MGPSTOV,  UMSAT,  UMPRR 

Master's  Navigation  solution, 
along  with  master  GPS  data 

SNAV_VAL_IND 

2,3,4 

Self  Navigation  Validity- 
Indicator 

EST__SNAV 

1,2, 3, 4 

SLAT,  SLON,  SALT, 

SEVEL,  SNVEL,  SALTR, 
SNAVTOV 

Navigation  solution  from  L16 
OCP 

MS_IND 

2,3,4 

Mas ter /Slave  indicator 

TRXJE_SNAV 

1,2 

TSLAT,  TSLON,  TSALT, 
TLATR,  TLONR,  TSALTR, 
TSNAVTOV 

TRUE  SELF  navigation  solution 

TRUE_MNAY  ^ 

TMLAT,  TMLON,  TMALT, 
TMLATR,  TMLONR, 

TMALTR,  TMNAVTOV 

TRUE  MASTER  navigation 
solution 

TRUE_CLOCK_BIAS 

BCTRUE 

TRUE  clock  bias 

TRUE_FREQ_DRI FT 

1,2 

FCTRUE 

TRUE  frequency  drift 

PPLI_DATA 

4 

Requested  PPLI 

RTT_DATA 

4 

Requested  RTT 

CSCI_VERSION 

CSCI_VERS_ID 

Denotes  operational  version 

RF_OPR_SW 

Reset/Initiate  signal  from 

Host  pilot 

SELF_GPS_DATA 

USSAT,  USPRR,  SGPSTOV, 
GPS_HEALTH_IND 

Received  GPS  data  from  HOST 

RF_ENABLE 

ON/OFF  switch 

GPS_VAL__IND 

2,3,4 

GPS  validity  Indicator 

EPHEM_DATA 

2,3,4 

EPHEM(30, 23) 

Ephemeris  satellite  data 
received  from  the  host  for 
pseudorange  calculations 

Table  4.4-1:  DGPS  RF  Inputs 
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Outputs 

Version 

Definition 

Description 

MASTER_MSG 

2,3,4 

MNAVT0V,MLAT,  MLON, 

MALT,  MEVEL,  MNVEL, 
MALTR,  GPS_HEALTH_IND, 
MGPSTOV,  UMSAT,  UMPRR 

Master's  Navigation 
solution,  along  with  master 
GPS  data 

RF_RESULTS_DATA 

4 

XA,  PA 

Refinement  Filter 
corrections  and  covariance 
message  sent  to  L16  OCP  for 

AF 

! 

RF_HEALTH_ 

STATUS__MSG 

1,2, 3, 4 

RF_STATE, 

RF_STATUS_IND,  XA,  PA, 
SCOUNT,  SATVIS, 

SNAVTOV 

Indicates  health  of  the 
refinement  filter  to  the 
host  to  determine  whether 
the  filter  should  be  reset, 
switch  to  backup  mode,  or 
system  normal . 

Table  4.4-2:  DGPS  RF  Outputs 


The  DGPS  RF  algorithm  is  comprised  of  seven  CSCs  whose  identification  and  general 
description  are  summarized  in  Table  4.4-3,  below. 


CSC 

Description 

RF_EXEC_CTRL 

Controls  the  data  flow  within  Refinement  Processing 
depending  on  inputs  to  the  system. 

RF_SOURCE_DATA_PROCESSING 

Prepares  and  synchronizes  all  data  for  Kalman 
filtering . 

RF_KALMAN_PROCESS ING 

Applies  Kalman  filtering  to  the  data  passed  from 
the  RF_SOURCE_DATA_PROCESSING  unit. 

HOST_INTERFACE_PROCESSING 

Interfaces  with  host  and  processes  data  that  enters 
this  system  from  the  host,  mainly  control  signals 
and  GPS  data. 

OCP_INTERFACE_PROCESSING 

L16  OCP  interface  from  which  all  OCP  data  enters 
the  system,  mainly  navigation  solution  including 
position,  velocity,  and  time. 

BUI LD_MASTER_MES SAGE 

Called  if  the  platform  is  designated  the  master  of 
the  network  from  the  host .  The  master  message 
contains  master  navigation  data  and  is  sent  at  a  2 

Hz  rate  to  all  the  members  in  the  network. 

BUILD_RF_RESULTS_MESSAGE 

Outputs  DGPS  RF  solution,  status,  and  covariance  to 
host . 

Table  4.4-3:  DGPS  RF  7  main  Computer  Software  Components 
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Figure  4.4-2:  Level  1  System  Architecture 


The  following  sections  provide  brief  technical  descriptions  of  each  of  the  seven  CSCs.  A 
Software  Design  Document  for  the  DGPS  RF  CSCI  is  presented  in  Appendix  A. 
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4.4.1  RF_EXEC_CTRL 


CSCLVERS_ID(I,2,  3,4) 


Figure  4.4-3:  RF_EXEC_CTRL  Level  1  Breakdown 


The  Refinement  Filter  Executive  Control  is  the  primary  control  element  of  the  DGPS  RF 
algorithm.  A  fundamental  requirement  of  the  algorithm  is  the  pre-existence  of  a  stable 
community  navigation  solution,  as  provided  by  conventional  Link- 16  navigation.  The  required 
indicators  for  this  condition  are:  (a)  Self-navigation  valid  and  (b)  Master  navigation  valid,  both 
of  which  are  provided  by  OCP_INT_PROC.  Also  required  for  algorithm  operation  is  the 
presence  of  valid  GPS  pseudorange  and  ephemeris  data,  as  well  as  algorithm  selection  by  the 
operator.  All  of  the  above  conditions  must  be  satisfied  prior  to  the  initialization  and  execution  of 
the  algorithm. 


When  conditions  exist  to  begin  algorithm  execution,  RF_EXEC_CTRL  shall  invoke  the 
various  sub-elements  of  the  program,  as  appropriate. 


) 
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RF  STATUS  TNDTCATOR  TRSD 

The  RSI  indicates  the  status  of  the  filter  and  locates  the  source  of  RF  operation  failure. 


RSI 

Status 

Conditions 

0 

RF  Inoperative 

Off  Selected 

1 

RF  Inoperative 

SNAV_VAL_IND  =  invalid 

2 

RF  Inoperative 

MNAV_VAL_IND  =  invalid 

3 

RF  Inoperative 

GPS  failure 

4 

RF  Operative 

Normal  Mode  /  Non  Steady  State 

5 

RF  Operative 

Normal  Mode  /  Steady  State 

6 

RF  Operative 

Backup  /  Non  Steady  State 

7 

RF  Operative 

Backup  /  Steady  State 

8 

RF  Master  Mode 

9 

RF  Observation  Failure  Reset  Command 

Table  4.4-4:  RF_STATUS_INDICATOR  description 


RF  STATE 


The  RF_EXEC_CTRL  is  modeled  as  a  finite  state  machine,  directly  corresponding  to  the 
actual  state  of  the  Refinement  Filter,  which  can  be  in  one  of  7  states.  The  RF_EXEC_CTRL 
determines  the  state  of  the  filter  according  to  validity  checks  and  the  health  of  data  and 
observations.  The  states  are  defined  as  follows: 


State  0  -  Initial  startup  state,  RF  reset 

•  If  the  filter  should  fail  any  validity  check,  become  instable,  or  obtain  deficient 
observations,  it  returns  to  this  state 

State  1  -  Master  designation 

•  Requires  no  Kalman  Processing 

State  2  -  Slave  designation  /  not  yet  initialized 

•  Initializes  filter  variables 

■  PA,  PX,  QA,  RA 

•  RTT_REQUEST  =  OFF 

State  3  -  Slave  Designation  /  GPS  Pseudorange  -  steady  state  not  achieved 

•  Normal  mode 

•  Filter  working,  not  yet  steady  state 

State  4  -  Slave  Designation  /  GPS  Pseudorange  -  steady  state  achieved 

•  state  at  which  RF  will  most  likely  exist 


State  5  -  Slave  Designation  /  RTT,  PPLI  -  backup  mode  initialization  (not  steady  state) 
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•  GPS  problem 

■  Insufficient  signal  strength 

■  Number  of  satellites  in  view  fall  under  minimum  requirement 

•  RTT_REQUEST  =  ON 

•  Using  PPLI/RTT  in  Kalman  Processing 

•  Reconfigure  RF:  5  8  states 

•  Steady  state  not  yet  achieved 

State  6  -  Slave  Designation  /  backup  mode  -  steady  state  achieved 

•  Backup  until  GPS  becomes  available 

RF_EXEC_CTRL  switches  between  states  when  the  state  of  the  data  changes.  If 
RF_EXEC_CTRL  resides  in  State  4,  and  then  GPS  becomes  weak  due  to  the  number  of  satellites 
available,  or  if  the  health  indicator  has  fallen  below  the  minimum  requirement,  then 
RF_EXEC_CTRL  falls  into  State  5  and  begins  requesting  PPLI  transmissions  from 
OCP_INT_PROC  CSC. 

The  backup  mode,  indicated  by  State  6,  is  used  when  GPS  data  becomes  temporarily 
unavailable.  In  this  mode,  PPLI  data  from  the  master  platform  is  used  as  an  observation  to  the 
DGPS  Kalman  Filter  to  maintain  the  error  state  solution. 

Figure  4.4-4  on  the  next  page  illustrates  the  7-state  state  transition  conditions  for  the  RF. 
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CSC  Inputs 

Version 

Definition 

Description 

CSCI_VERS_ID 

1,2, 3, 4 

Denotes  operational  version 

GPS_HEALTH_IND 

2,3,4 

Indicates  the  health  status  of 
GPS  signal.  When  this  signal 
is  too  weak,  backup  mode  takes 

over. 

MMS 

2,3,4 

Master  Message  Indicator: 

Check  if  the  master  message  is 
ready  for  transmission 

MS_IND 

2,3,4 

Master/Slave  Indicator:  Checks 
for  pilot  designation  for 
platform  either  master  or  slave 
aircraft . 

RF_ENABLE 

2,3,4 

On/Off  Switch 

RF_KALMAN_RESULTS_ 

PKG 

1,2, 3, 4 

Time  (TC) , 
RF__STATE,  RSI, 
XA,  PA 

Refinement  Filter  results  and 
covariance,  XA  and  COV 

RF_OPR_SW 

1,2, 3, 4 

Refinement  filter  operation 
switch:  ON/OFF  switch  for 
system  initialization/reset 

GPS_VAL_IND 

2,3,4 

Master  Navigation  Validity 
Indicator 

SNAV_VAL_IND 

2,3,4 

Self  Navigation  Validity 
Indicator 

Table  4.4-5:  RF_EXEC_CTRL  Inputs 


CSC  Outputs 

Version 

Description 

CSCI_VERS_ID 

1,2, 3, 4 

Denotes  operational  version 

RF_HEALTH_STAT_MSG 

1,2, 3, 4 

RF_STATE, 
RF__STATUS_IND, 
XA,  PA,SCOUNT, 
SATVIS,SNAVTOV 

Indicates  health  of  the 
refinement  filter  to  the  host 
to  determine  whether  the  filter 
should  be  reset,  switch  to 
backup  mode,  or  system  normal. 

RF_STATE 

3,4 

Indicates  the  state  value  of 
the  refinement  filter  (See 
below  for  definitions  of 
states) .  [OUTPUTS  TO 

OCP_INT_PROC] 

RF_STATE 

1,2, 3, 4 

Indicates  the  state  value  of 
the  refinement  filter  (See 
below  for  definitions  of 
states) .  [OUTPUTS  TO 

RF_Kalman_Proc  Module] 

Table  4.4-6:  RF_EXEC_CTRL  Outputs 
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Figure  4.4-5:  STATE  0  PROCESSING  -  Startup  state  /  RF  reset 
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Figure  4.4-6:  STATE  0  PROCESSING  (cent) 
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Figure  4.4-7:  STATE  1  PROCESSING  -  Master  Designation  /  initialization 
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Filter/variable 

Initialization 


CALL 

HOST_INT_PROC 


RF_OPR_SW 


SET: 

RSI  =  0 

RF.STATE  =  0 


CALL 

OCP_INT_PROC 


SNAV_VAL_ 
IND  =  valid? 


SET: 

RSI=1 

RF_STATE  =  0 


GPS_VAL_ 
L\D  =  valid? 


SET: 

RSI  =  3 

RF  STATE  =  0 


MNAV_VAL_ 
IND  =  valid? 


SET: 

RSI  =2 

RF_STATE  =  0 


SET: 

RSI  =  6 

RF  STATE  =  5 


INSUFRCIENT 


GPS 

Strength/#? 


GENERATE 

RF_HEALTH_ 

STATUS_MSG 


Figure  4.4-8:  STATE  2  PROCESSING  -  Slave  Designation  /  initialization 
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CALL 

HOST_INT_PROC 


RF  OPR.SW 


SET: 

RSI  =  0 

RF  STATE  =  0 


CALL 

OCP_INT_PROC 


SNAV_VAL_ 
IND  =  valid? 


SET: 

RSI=1 

RF_STATE  =  0 


GPS_VAL_ 
IND  =  valid? 


SET: 

RSI  =3 

RF_STATE  =  0 


MNAV_VAL_ 
IND  =  valid? 


SET: 

RSI  =2 

RF_STATE  =  0 


SET: 

RSI  =  6 

RF_STATE  =  5 


^INSUFnCIENT 


GPS 

Strength/#? 


CALL 

RF_SOURCE_DATA_P 

ROC 

CALL 

Rr_KALMAN_PROC 

SET: 

RSI  =  5 

RF_STATE  =  4 


Steady  State? 


METRIC  <SSLIM 


GENERATE 
RF_HEALTH_ 
STATUS  MSG 


Figure  4,4-9:  STATE  3  PROCESSING  -  Slave  Designation  /  GPS  Pseudorange  [not  steady  state] 
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CALL 

HOST  BNT.PROC 


RF_OPR_SW 


SET: 

RSI  =  0 

RF_STATE  =  0 


CALL 

OCP_INT_PROC 


SNAV_VAL_ 
IND  =  valid? 


SET: 

RSI=1 

RF_STATE  =  0 


GPS„VAL_ 
^TND  =  valid?^ 


SET: 

RSI  =  3 

RF_STATE  =  0 


MNAV_VAL_ 
IND  =  valid? 


SET: 

RSI  =  2 

RF_STATE  =  0 


SET: 

RSI  =6 

RF_STATE  =  5 


^INSUFFICIENT 


GPS 

Strength/#? 


GENERATE 

RF_HEALTH_ 

STATUS_MSG 


Figure  4,4-10:  STATE  4  PROCESSING  -  Slave  Designation  /  GPS  Pseudorange  [steady  state] 
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CALL 

HOST_INT_PROC 


RF_OPR_SW 


SET: 

RSI  =  0 

RF  STATE  =  0 


RTT_REQUEST_ 

IND 


CALL 

OCP_INT_PROC 


SNAV__VAL_ 
IND  =  valid? 


SET: 

RSI=1 

RF_STATE  =  0 


MNAV_VAL_ 
IND  =  valid? 


SET: 

RSI  =  2 

RF_STATE  =  0 


SET: 

RSI  =  4 

RF_STATE  =  2 


GPS 

Strength/#? 


INSUFFICIENT 


CALL 

RF  SOURCE_DATA_P 
ROC 

1 _ 

CALL 

RF_KALMAN_PROC 

SET: 

RSI  =  7 

RF  STATE  =  6 


Steady  State? 


METRIC  <  SSLIM 


GENERATE 

RF_HEALTH_ 

STATUS_MSG 


Figure  4.4-11:  STATE  5  PROCESSING  -  Slave  Designation  /  RTT,  PPLI  [backup  mode] 
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CALL 

HOST_INT_PROC 


RF_OPR_SW 


SET: 

RSI=0 

RF_STATE  =  0 


CALL 

OCP_INT_PROC 


SNAV„VAL_ 
IND  =  valid? 


SET: 

RSI=1 

RF_ST  ATE  =  0 


MNAV_VAL_ 
IND  =  valid? 


SET: 

RSI  =2 

RF_STATE  =  0 


SET: 

RSI  =  4 

RF  STATE  =  2 


^SUFnCIENT 


GPS 

Strength/#? 


INSUFFICIENT 


GENERATE 

RF_HEALTH_ 

STATUS_MSG 


Figure  4.4-12:  STATE  6  PROCESSING  -  Slave  Designation  /  backup  mode  [steady  state] 
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4.4.2  RF_SOURCE_DATA_PROC 


Figure  4.4-13;  RF_SOURCE_DATA_PROC  Level  1  Breakdown 


The  Refinement  Filter  Source  Data  Processing  unit  synchronizes  and  prepares  data  for 
Kalman  processing.  It  is  essential  that  all  data  is  time  synchronized  before  the  Kalman  filter  can 
be  applied. 

The  RF_SOURCE_DATA_PROC  receives  the  true  and  estimated  navigation  and  GPS 
data  for  both  the  master  and  slave.  The  master’s  GPS  and  navigation  data  is  extracted  from  the 
Master  message-derived  navigation  data  package  and  then  paired  with  platform’s  own  navigation 
solution. 

CSCI_VERS_ID  value  is  passed  from  the  RF_EXEC  CTRL  to  determine  which  modes 
of  system  operation  (i.e  laboratory  or  field)  should  be  executed.  Figure  4.4-14  is  a  breakdown  of 
the  SLCSCs  in  the  RF_SOlJRCE_PROC.  Table  4.4-7  lists  the  SLCSCs  and  their  corresponding 
functions.  This  table  also  indicates  the  software  versions  in  which  the  SLCSC  shall  be  utilized. 
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I 


RF_  SOURCE_DATA_EXEC 


COMPARE_SAT_ 

INDICES 


XFORM  _NAV_COORD 


compute_sat_ 

COMPUTE_SAT_ 

CIRC.ECEF 

ELLIP.ECEF 

PROCESS_PR_DATA 


COMPUTE_SAT_ 

COMPUTE_SAT_ 

LAB_VIS 

FIELD.VIS 

PPLLRTT_SCREEN 


GENERATE_KALMAN 


r%i>o  O’C'T' 


Figure  4.4-14:  RF_SOURCE_DATA_PROC  Level  2  breakdown 


I 
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SLCSC 


Description 


RF  SOURCE  DATA  EXEC 


COMPARE  SAT  INDICES 


Coordinates  self  navigation  (HOST)  with  master 
navigation  solution  (OCP) . 

Compares  measured  satellite  indices  for 
master/slave . 

Selects  candidate  observation  group  for  common 


elements . 

COMPUTE_SAT_CIRC_ECEF 

Computes  Satellite  ECEF  elements  for  common 
satellites  when  CSCI_VERS_ID  =2.0  (Laboratory 

Mode ) 

COMPUTE_SAT_ELLI P_ECEF 

Computes  Satellite  ECEF  elements  for  common 
satellites  when  CSCI_VERS_ID  =3.0  (Field  Mode) 

COMPUTE  _SAT_LAB  _VIS 

Only  satellites  at  least  5°  above  horizon  are 
candidates  when  CSCI__VERS_ID  =  2.0  (Laboratory 

Mode) 

COMPUTE  _SAT_FIELD  _VIS 

Only  satellites  at  least  5°  above  horizon  are 
candidates  when  CSCI  VERS  ID  =  3.0  (Field  Mode) 

XFORM  NAV  COORD 


PPLI  RTT  SCREEN 


PROCESS  PR  DATA 


GENERATE  KALMAN  OBS  SET 


Transforms  self -navigation  into  Local  Level  and 
ECEF  coordinates . _ 

Called  only  when  CSCI_VERS_ID  =4.0  (Backup  Mode) 
Takes  PPLI /RTT  Data  when  GPS  is  not  valid. 

Converts  satellite  code  phase  data  from  master  and 
self  to  generate  arrays  of  psuedorange  data  from 
all  common  satellites  in  units  of  meter 

Generates  Kalman  Observation  set  from  Satellite  or 
PPLI /RTT  Data 


Table  4.4-7:  RF30URCE_DATA_^PR0C  SLCSC  Descriptions 


Additional  processing  is  required  for  Version  3.0  in  order  to  synchronizemaster  and  self 
data.  For  Version  2.0,  a  circular  orbit  model  is  used,  since  it  is  an  excellent  representation  of  the 
actual  GPS  satellite  orbital  dynamics.  However,  for  Version  3,  the  GPS  satellite  pseudorange 
data  requires  the  implementation  of  the  true  elliptical  satellite  model  by  using  ephemeris  data  for 
each  of  the  participating  satellites. .  The  circular  and  elliptical  satellite  models  are  both  used  to 
locate  satellites  within  the  ECEF  coordinate  frame  at  specified  times.  It  is  also  essential  to 
convert  the  master  and  self  coordinates  into  the  ECEF  coordinate  frame.  Both  satellite  and 
platform  coordinates  in  ECEF  are  computed,  and  then  both  are  transformed  into  Local  Level 
coordinates  and  difference  vector  DIFF  is  generated.  The  DIFF  vector  is  used  to  compute  the 
elevation  of  the  satellites  to  determine  and  eliminate  the  satellites  that  do  not  achieve  at  least  five 
degrees  of  elevation  from  filter  consideration.  The  direction  cosine  shall  be  generated  as 
functions  of  member  platform  positions  and  the  ECEF  positions  of  the  satellites,  as  computed  via 
satellite  ephemeris  data. 

The  RF_SOURCE_DATA  PROC  generates  a  Kalman  Observation  Set  Package  from  the 
satellites  or  from  PPLI/RTT  to  output  to  the  RF_KALMAN_PROC  CSC. 
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The  data  included 


in  this  package  is  the  following: 

HA  (12, 8)  -  Observation  Matrix 
YA  (INDEX)  -  Observation  Measurement  Vector 
YAEXP  (INDEX)  -  Observation  Predicted  Vector 
SATVIS  (j)  -  Satellite  Visibility  Vector 

DXTRUE,  DYTRUE,  DZTRUE  -  True  Navigation  Error  Composites 
BCTRUE  -  True  Clock  Bias 
FCTRUE  -  True  Frequency  Drift 


The  generation  of  the  package  is  created  by  performing  a  defined  set  of  computations  and 
data  transfers  which  is  described  in  detail  in  the  SRS.  The  Kalman  Observation  Set  Package 
includes  the  same  data  for  all  versions  however  the  computations  of  these  values  differ  according 
to  the  version  being  utilized.  Figures  4.4-15  and  4.4-16  represent  a  functional  flow  chart  for 
RF_SOURCE_DATA_PROC. 
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INPUTS 

DESCRIPTION 

MNAV  DATA 

MNAVTOV 

Time  of  Validity  of  MASTER  Navigation  solution 

MliAT 

ESTIMATED  MASTER  Latitude  position  [rad] 

MLATR 

ESTIMATED  MASTER  Latitude  rate  [rad/s] 

MLON 

ESTIMATED  MASTER  Longitude  position  [rad] 

MLONR 

ESTIMATED  MASTER  Longitude  rate  [rad/s] 

MALT 

ESTIMATED  MASTER  Altitude  [m] 

MALTR 

ESTIMATED  MASTER  Altitude  rate  [m/s] 

TMIiAT* 

TRUE  MASTER  Latitude  position  [rad] 

TMLATR* 

TRUE  MASTER  Latitude  rate  [rad/s] 

TMLON* 

TRUE  MASTER  Longitude  position  [rad] 

TMLONR* 

TRUE  MASTER  Longitude  rate  [rad/s] 

TMALT* 

TRUE  MASTER  Altitude  [m] 

TMALTR* 

TRUE  MASTER  Altitude  rate  [m/s] 

MSAT(12)** 

MASTER  Ordered  Satellite  List 

MPRR(12)** 

MASTER  Ordered  measured  code  phase  array 

MGPSTOV** 

MASTER  predicted  GPS  time  of  validity 

MVIS** 

Number  of  satellites  visible  to  MASTER 

BCTRUE 

TRUE  MASTER  Clock  Bias 

FCTRUE 

TRUE  MASTER  Frequency  Drift 

SNAV  DATA 

SNAVTOV 

Time  of  Validity  of  SELF  Navigation  solution 

SLAT 

ESTIMATED  SELF  Latitude  position  [rad] 

SLATR 

ESTIMATED  SELF  Latitude  rate  [rad/s] 

SLON 

ESTIMATED  SELF  Longitude  position  [rad] 

SLONR 

ESTIMATED  SELF  Longitude  rate  [rad/s] 

SALT 

ESTIMATED  SELF  Altitude  [m] 

SALTR 

ESTIMATED  SELF  Altitude  rate  [m/s] 

TSLAT* 

TRUE  SELF  Latitude  position  [rad] 

TSLATR* 

TRUE  SELF  Latitude  rate  [rad/s] 

TSLON* 

TRUE  SELF  Longitude  position  [rad] 

TSLONR* 

TRUE  SELF  Longitude  rate  [rad/s] 

TSALT* 

TRUE  SELF  Altitude  [m] 

TSALTR* 

TRUE  SELF  Altitude  rate  [m/s] 

SSAT{12) ** 

SELF  Ordered  Satellite  List 

SPRR{12) ** 

SELF  Ordered  measured  code  phase  array 

SGPSTOV** 

SELF  predicted  GPS  time  of  validity 

SVIS** 

Number  of  satellites  visible  to  SELF 

BCTRUE 

TRUE  SELF  Clock  Bias 

FCTRUE 

TRUE  SELF  Frequency  Drift 

INVERSOO)  ** 

Satellite  sorting  index 

EPHEM{30,23) ** 

Satellite  Ephemeris  Data 

CSCI  VERS  IND 

CSCI  Version  Indicator 

NVS 

Number  of  Visible  Satellites 

RF  STATE 

State  the  Refinement  Filter  resides 

*  -  Provided  only  if  CSCI_VERS_IND  =  2  (V ersion  2.0) 
**  -  Provided  only  if  CSCI_VERS_IND  =  3  (Version  3.0) 
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OUTPUTS 

DESCRIPTION 

MNAV  DATA 

MNAVTOV 

Time  of  Validity  of  MASTER  Navigation  solution 

MLAT 

ESTIMATED  MASTER  Latitude  position  [rad] 

MLATR 

ESTIMATED  MASTER  Latitude  rate  [rad/s] 

MLON 

ESTIMATED  MASTER  Longitude  position  [rad] 

MLONR 

ESTIMATED  MASTER  Longitude  rate  [rad/s] 

MALT 

ESTIMATED  MASTER  Altitude  [m] 

MALTR 

ESTIMATED  MASTER  Altitude  rate  [m/s] 

TMLAT* 

TRUE  MASTER  Latitude  position  [rad] 

TMLATR* 

TRUE  MASTER  Latitude  rate  [rad/s] 

TMLON* 

TRUE  MASTER  Longitude  position  [rad] 

TMLONR* 

TRUE  MASTER  Longitude  rate  [rad/s] 

TMALT* 

TRUE  MASTER  Altitude  [m] 

TMALTR* 

TRUE  MASTER  Altitude  rate  [m/s] 

MSAT(12) ** 

MASTER  Ordered  Satellite  List 

MPRR(12) ** 

MASTER  Ordered  measured  code  phase  array 

MGPSTOV** 

MASTER  predicted  GPS  time  of  validity 

MVIS** 

Number  of  satellites  visible  to  MASTER 

BCTRUE 

TRUE  MASTER  Clock  Bias 

FCTRUE 

TRUE  MASTER  Frequency  Drift 

SNAV  DATA 

SNAVTOV 

Time  of  Validity  of  SELF  Navigation  solution 

SLAT 

ESTIMATED  SELF  Latitude  position  [rad] 

SLATR 

ESTIMATED  SELF  Latitude  rate  [rad/s] 

SLON 

ESTIMATED  SELF  Longitude  position  [rad] 

SLONR 

ESTIMATED  SELF  Longitude  rate  [rad/s] 

SALT 

ESTIMATED  SELF  Altitude  [m] 

SALTR 

ESTIMATED  SELF  Altitude  rate  [m/s] 

TSLAT* 

TRUE  SELF  Latitude  position  [rad] 

TSLATR* 

TRUE  SELF  Latitude  rate  [rad/s] 

TSLON* 

TRUE  SELF  Longitude  position  [rad] 

TSLONR* 

TRUE  SELF  Longitude  rate  [rad/s] 

TSALT* 

TRUE  SELF  Altitude  [m] 

TSALTR* 

TRUE  SELF  Altitude  rate  [m/s] 

SSAT(12) ** 

SELF  Ordered  Satellite  List 

SPRR(12) ** 

SELF  Ordered  measured  code  phase  array 

SGPSTOV** 

SELF  predicted  GPS  time  of  validity 

SVIS** 

Number  of  satellites  visible  to  SELF 

BCTRUE 

TRUE  SELF  Clock  Bias 

FCTRUE 

TRUE  SELF  Frequency  Drift 

INVERSOO)** 

Satellite  sorting  index 

EPHEM(30,23) ** 

Satellite  Ephemeris  Data 

CSCI  VERS  IND 

NVS 

RF  STATE 

Table  4.4-9:  RF_SOURCE_DATA_PROC  Outputs 


*  -  Provided  only  if  CSCI_VERS_IND  =  2  (Version  2.0) 
**  -  Provided  only  if  CSCI_VERS_IND  =  3  (Version  3.0) 
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■  FIRST  CALL- USE  EST  , 

I  NAV  DATA  I 

;  MLLPX  i 

!  MLLP  =  MLLPY  | 

!  MLLPZ  : 

^  _  SLLPX  I 

!  SLLP  =  SLLPY  : 

I  SLLPZ  ! 

; _ j 


SECOND  CALL -USE 
TRUE  NAV  DATA 

TMLLPX 
TMLLP  =  TMLLPY 

__ 

TSLLPX 
TSLLP  =  TSLLPY 
TSLLPZ 


Figure  4,4-15:  RF_SOURCE_DATA_EXEC  Logical  data  flow  diagram 
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4.4.3  RF_KALMAN_PROC 


Figure  4.4-17:  RF_KALMAN_PROC  Level  1  Breakdown 


The  RF_KALMAN_PRC)C  performs  the  Extended  Kalman  Filter  (EKF)  processing  needed  to 
estimate  the  numeric  values  of  the  eight  Refinement  Filter  Error  terms  defined  as  follows: 

•  XA(1):  LL  x-coordinate  relative  position  error  [m] 

•  XA(2):  LL  x-coordinate  relative  position  error  rate  [m/s] 

•  XA(3):  LL  y-coordinate  relative  position  error  [m] 

•  XA(4):  LL  y-coordinate  relative  position  error  rate  [m/s] 

•  XA(5):  LL  z-coordinate  relative  position  error  [m] 

•  XA(6):  LL  z-coordinate  relative  position  error  rate  [m/s] 

•  XA(7):  Relative  clock  bias  [ns] 

•  XA(8):  Relative  frequency  drift  [ns/s] 

The  observation  set  required  for  the  refinement  process  is  generated  by 
RF_SOURCE_DATA_PROC.  This  package  contains: 

•  Observation  matrix 

•  Final  number  of  paired  satellites  visible  above  5°  elevation 

•  Observation  measurement  vector 

•  Observation  prediction  vector 

•  Reference  time  at  which  measurements  are  valid  since  GPS  time  of  week  [s] 

•  Ordered  array  of  common  visible  satellites  above  5°  elevation 

•  True  error  composites 

•  True  clock  bias 

•  True  frequency  drift. 
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The  results  from  the  Kalman  filtering  consists  of  a  data  package  with  the  following  information: 

•  Observation  set  time  of  validity 

•  RF  State 

•  Refinement  Filter  Status  Indicator 

•  Refinement  Filter  Solution  Vector 

•  Error  covariance 

•  Error 


As  part  of  the  operation  of  the  Kalman  Filter,  RF_KALMAN_PROC  shall  also  perform  the 
initialization  of  the  EKF  matrix  elements. 


CSC  INPUTS 

DESCRIPTION 

KALMAN  OBS_SET 

HA(12,8) 

Observation  matrix 

SCOUNT 

Final  number  of  paired  satellites  visible  above  ANGLIM 

YA(I) ,  I  =  1,  14 

Observation  measurement  vector 

YAEXPd),  1  =  1,  14 

observation  prediction  vector 

TC,  TOLD 

Reference  time  at  which  measurements  are  valid  since  GPS 

time  of  week  [s] 

SATVlS(j) , 

Ordered  array  of  common  visible  satellites  above  ANGLIM 

j  =  1,  SCOUNT 

DXTRUE 

True  XYZ  direction  error  composites.  Only  used  when 

DYTRUE 

CSCI  VERS  ID  =  2.0  (Laboratory  Mode) 

DZTRUE 

BCTRUE 

True  clock  bias 

FCTRUE 

True  frequency  drift. 

PPL1_DATA 

Used  only  when  the  RF  State  is  in  Backup  Mode  (when  GPS 

RTT  DATA 

is  either  not  on  or  valid) .  Contains  pseudo  range  data 

RF  STATE 

Indicates  the  state  value  of  the  refinement  filter 

RSI 

Refinement  Status  Indicator 

Table  4.4-10:  RF_KALMAN_PROC  Inputs 
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CSC  OUTPUTS 

DESCRIPTION 

RF_KALMAN_RESULTS_PKG 

TC 

RF_STATE 

RSI 

XA(k)  ,  k  =  1,  8 

SIGX 

SIGY 

SIGZ 

SIGBC 

SIGFC 

ERRX 

ERRY 

ERRZ 

ERRBC 

ERRFC 

Observation  set  time  of  validity 

Indicates  the  state  value  of  the  refinement  filter 
Refinement  Filter  Status  Indicator 

Refinement  Filter  Solution  Vector 

COVARIANCE  DIAGONAL  TERMS 

ERROR  TERMS 

SCOUNT 

Final  number  of  paired  satellites  visible  above  ANGLIM 

SATVIS(j)  , 

j  =  1,  SCOUNT 

Ordered  array  of  common  visible  satellites  above  ANGLIM 

Table  4.4-11:  RF_KALMAN_PROC  Outputs 
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a.  ZERO  STATE  VECTOR 
!  ELEMENT 
j  XA(k)  =  0.0k  =  l,8 

!  b.  ZERO  STATE 
j  COVARIANCE 
j  PA(i,j)  =  0.0  i,j  =  l,8 

i  c.  SET  COVARIANCE 
j  DIAGONAL  TERMS 
PA(l,l)=POSX 
!  PA(3,3)  =  POSX 

j  PA(5,5)  =  POSX 

PA(7,7)  =  BCX 
I  PA(8,8)=FCX 

i 

;  d.  ZERO  PROCESS  NOISE 
!  MATRIX 
I  Q(i,j)  =  0.0  i,j  =  l,8 

I 

:  e.  SET  PROCESS  NOISE 
!  DIAGONAL  TERMS 
i  QA(1,1)  =  PNX 

QA(3,3)  =  PNX 

*  QA(5,5)  =  PNX 

i  QA(7,7)  =  BCPNX 

j  QA(8,8)  =  FCPNX 

i  f  ZERO  OBSERVATION 
j  NOISE  MATRIX 
RA(12,12) 

!  g-  SET 

•  RA(1,1)=RNX 

!  RA(2,2)  =  RNX2 

I  PA(k,k)  =  RNX3 
i  k  =  3, 12 


Figure  4.4-18:  RF_KALMAN_PROC  Logical  data  flow  diagram 
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Figure  4.4-19:  RF_KALMAN_PROC  Logical  data  flow  diagram  (cont) 
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B 


COMPUTE 
COVARIANCE 
DIAGONAL 
SQUARE  ROOTS 


SIGX  =DSQRT(PA(1, 1)) 
SIGY  =DSQRT(PA(3,3)) 
SIGZ  =  DSQRT  (PA  (5,  5)) 
SIGBC  =  DSQRT  (PA  (7,  7)) 
SIGFC  =  DSQRT  (PA  (8,  8)) 


CHECK  FOR  STEADY 
STATE  ACHEIVED 


METRIC  =  DSQRT  (PA  (1, 1)  +  PA  (3, 3) 
+  PA(5,  5)) 


SET 

RF.STATUS 
INDICATOR  =  4 


SET 

RF_STATUS 
INDICATOR  =  5 


ASSEMBLE 

RF„KALMAN_ 

RESULTS.PKG 


r' 


TIME  (TC) 

RF_STATE 

RF_STATUS_INDICATOR 
XA  STATE  VECTOR  VALUES 
COVARIANCE  DIAGONAL  TERMS 
ERROR  TERMS 
SCOUNT 

SATVIS  (SCOUNT) 


EXIT 


D 


Figure  4.4-20:  RF_KALMAN_PROC  Logical  data  flow  diagram  (cont) 
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4.4.4  OCP_INT_PROC 


Figure  4.4-21:  OCP_INT_PROC  Level  1  breakdown 

The  OCP  interface  Processing  provides  a  two-way  interface  between  the  Link- 16 
Operational  Software  and  DGPS  RF  processing.  This  interface  is  responsible  for  the  following 
general  functions: 

(a)  Decomposition  of  received  Master  Message  to  extract  and  format  master  navigation 
data  and  measured  GPS  pseudorange  information,  both  of  which  are  required  within 
the  DGPS  RF  algorithm. 


Application  ofDGPS  to  L16  Navigation 


Page  133 


(b)  Rescaling  of  our  navigation  data  from  English  to  Metric  units  for  use  within  the 
DGPS  RF  algorithm. 

The  Master  Message  is  a  TADIL-J  message  received  via  normal  LI  6  message 
processing.  Our  navigation  data  is  derived  from  either  L16  navigation  solution  (Versions  3.0, 
4.0)  or  from  LNS  simulator  data  (Versions  1 .0, 2.0). 

If  platform  is  designated  as  “Master”,  then  the  algorithm  -  generated  message  that  is 
submitted  for  L16  transmitter  by  OCP_INT_PROC.  In  projected  Version  4.0,  RF  results  are 
provided  to  LI 6  OCP  for  inclusion  in  atmospheric  delay  compensation  processing. 


PROCESS. 

MASTER_MESSAGE 


CONVERT_NAV_DATA 


Figure  4.4-22:  OCP_INT_PROC  Level  2  Breakdown 


SLCSC 


PROCESS_MASTER_MESSAGE 


CONVERT_NAV_DATA 


Description 


Decomposes  the  received  Master  Message  Data  into  Master 
NAV  data  and  GPS  data 


Converts  L16  Nav  data  into  metric  units 


Table  4.4-12:  OCP_INT_PROC  SLCSC  Descriptions 
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CSC  Inputs 

Description 

CSCI_VERS_IND 

Denotes  Operational  Version 

RF_STATE 

Indicates  the  state  value  of  the  refinement  filter 

MASTER_MSG_ 

This  message  contains 

Master's  nav  solution 
master's  GPS  data 

PPLI  DATA 

Used  only  when  the  RF  State  is  in  Backup  Mode 

RTT  DATA 

(when  GPS  is  either  not  on  or  valid) .  Contains 

pseudo  range  data 

EST_SNAV 

ESTIMATED  SELF  Navigation  Data 

TRUE_SNAy_ 

TRUE  SELF  Navigation  Data 

TRUE__mAV 

TRUE  MASTER  Navigation  Data 

SNAV_VAL_IND 

Self  Navigation  Validity  Indicator 

MNAV_VAL_IND 

Master  Navigation  Validity  Indicator 

MS_IND 

Master/Slave  Indicator 

MMS 

Master  Message  Prepared  Signal 

RF_RESULTS_DATA 

Refinement  Filter  corrections  and  covariance  to 

send  to  AF  (used  when  CSCI  =  4,  Backup  Mode) 

Table  4.4-13:  OCP_INT_PROC  Inputs 


CSC  Outputs 

Description 

PPLI  DATA 

Used  only  when  the  RF  State  is  in  Backup  Mode 

RTT  DATA 

(when  GPS  is  either  not  on  or  valid) .  Contains 

pseudo  range  data 

MNAV_DATA 

MASTER  Navigation  Solution 

SNAV_DATA 

SELF  Navigation  Solution 

RF  RESULTS  MSG 

Refinement  Filter  corrections  and  covariance  to 

send  to  AF 

MASTER_MSG 

This  message  contains 

Master's  nav  solution 

Master's  GPS  data 

MS_IND 

Master/Slave  Indicator 

MMS 

Master  Message  Prepared  Signal 

SNAV_VAL_IND 

Self  Navigation  Validity  Indicator 

MNAV_VAL_IND 

Master  Navigation  Validity  Indicator 

CSCI_VERS_IND 

Denotes  Operational  Version 

Table  4.4-14:  OCP_INT_PROC  Outputs 
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MASTER 


CALL  PROCESS. 
MASTER. 
MESSAGE 

■  DECOMPOSE  MASTER  MESSAGE  INTO 

1  NAV  DATA  AND  GPS  DATA 

r 

ORDER  GPS  DATA  ' 

OUTPUTS  :  j 

CALL 

PROCESS.RAW. 
GPS  DATA 

■  MSAT 

"  MPRR  1 

■  MGPSTOV  : 

■  MVIS  • 

•  INVERS  (30)  i 

^  OUTPUT :  1 

■  MNAVTOV  1 

■  MLAT 

•  MLATR  ! 

■  MLON  j 

■  MLONR 

■  MALT  i 

■  MALTR  j 

r 

CALL 

CONVERT  NAV 
DATA 

(MASTER  EST  DATA) 

1 

r 

CA 

CONVEi 

DA 

(SELF  ES 

LL 

IT  NAV 

TA 

TDATA) 

OUTPUT :  '■ 

•  SNAVTOV  j 

■  SLAT 

■  SLATR  f 

SLONR 

SALT 

SAT.TR 


Figure  4.4-23:  OCP_INT_PROC  Logical  data  flow  diagram 
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OUTPUT : 


■ 

MNAVTOV 

■ 

TMLAT 

■ 

TMLATR 

■ 

TMIjON 

■ 

TMLONR 

■ 

TMALT 

■ 

TMAT.TR 

OUTPUT : 

■  SNAVTOV 

-  TSLAT 

■  TSLATR 

■  TSLON 

-  TSLONR 

■  TSALT 

■  TSALTR 

■  BCTRUE 

■  FCTRUE 


Figure  4.4-24:  OCP_INT_PROC  Logical  data  flow  diagram  (cont) 
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4.4.5  HOST_INT_PROC 


Figure  4.4-25:  HOST_INT_PROC  Level  1  breakdown 


The  host  Interface  Processing  function  serves  as  the  primary  two  way  data  path  between 
the  DGPS  RF  algorithm  and  the  host  processor.  With  respect  to  input  from  the  host,  it  performs 
the  following  functions: 

(a)  Interprets  and  reformats  DGPS  RF  control  inputs  provided  by  the  host,  namely: 

-  RF_ENABLE  (Operate/Non-operate  switch) 

-  RF_OPR_SW  (Operator  conunand  algorithm  reset  indicator) 

(b)  Interprets  and  reformats  raw  input  provided  by  the  GPS  receiver,  including  GPS 
validity  indicator,  Self-GPS  pseudorange  measurements,  and  ephemeris  data. 

With  respect  to  host  output,  HOST_INT_PROC  is  responsible  for  providing  an  RF 
Health  and  Status  Message,  which  includes  the  full  filter  state  estimates  and  co  variances  plus  RF 
State  and  Status  Indicators. 
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CSC  inputs  and  outputs  are  summarized,  respectively,  in  Tables  4.4-15  and  4.4-16.  Two 
SLCSCs  are  utilized  within  HOST_INT_PROC.  Their  functions  are  described  in  Table  4.4-17. 


CSC  Inputs 

Version 

Description 

RF_OPR_SW 

1,2, 3, 4 

Operator  Reset  Command 

RF_ENABLE 

2,3,4 

RF  Enable  Command 

SELF_GPS_DATA_ 

2,3,4 

Pseudorange  and  satellite  ID  message  data 

GPS_VAL_IND 

2,3,4 

GPS  Validity  Indicator 

EPHEM_RAW 

2,3,4 

Raw  Ephemeris  Data  message 

RF_JiEALTH_STATUS_MSG 

2,3,4 

Summary  of  GPS  results  and  status 

Table  4.4-15:  HOST_INT_PROC  Input  Variables 


CSC  Outputs 

Version 

Description 

RF_HEALTH_STATUS_MSG 

2,3,4 

Summary  of  GPS  results  and  status 

Table  4.4-16:  HOST_INT_PROC  Output  Variables 
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SLCSC 


EXTRACT  GPS  PSEUDORANGE 


BUILD  EPHEMERIS  TABLE 


Description _ 

Decomposes  GPS  receiver  data  to  provide  an 
ordered  array  of  satellite  ID's  and  code  phase 
data. _ 

Reformats  GPS  receiver  ephemeris  message  to 
provide  standard  ephemeris  array. 


Table  4,4-17:  HOST_INT_PROC  SLCSC  Descriptions 


4.4.6  Biiild_Master_Message 


SNAV  DATA.PKG  (2. 3, 4) 

f;--'  .  ' 

OCP_ 

INT_ 

'  BUILD, 

HOST 

PROC 

I  MASTER 

^  GPS_PR_DATA  (2.  3,  4) 

INT 

P  MSG 

PROC 

^  MASTER^MSG  (2,  3,  4) 

Figure  4.4-27:  BUILD_MASTER_MESSAGE  Level  1  breakdown 


The  purpose  of  this  function  is  to  construct  outgoing  Master  Messages  containing  self 
navigation  and  measured  pseudorange  data  collected  at  own  location.  This  function  shall  be 
invoked  only  when  own  platform  has  been  designated  as  Master. 


The  contents  and  format  of  the  J28.7  Master  Message  are  presented  in  paragraph  4.5.4. 
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4.4.7  BUILD_RF_RESULTS_DATA 


Figure  4.4-28:  BUn:.D_RF_RESULTS_DATA  Level  1  breakdown 


This  function  is  intended  as  a  place  holder  for  a  potential  enhanced  Version  4.0  of  the 
DGPS  RF  algorithm.  This  version  of  the  software  would  combine  the  functionality  of  the  DGPS 
RF  with  that  of  an  Atmospheric  Calibration  Filter  (AF),  now  being  developed  under  separate 
contract.  The  basic  concept  of  Version  4.0  is  to  improve  basic  Link- 16  navigation  performance 
via  advanced  atmospheric  calibration  of  TOA  range  measurements.  The  Atmospheric  Filter 
utilizes  the  position  estimates  of  the  transmitter  and  receiver  of  a  PPLI  message  as  basic  input. 
The  DGPS  RF  has  demonstrated  the  ability  to  reduce  errors  in  position  estimates  to  extremely 
small  levels.  These  precise  DGPS  RF  position  estimates  can  generate  a  corrective  term  that  will 
reduce  the  range  estimate  error  of  the  AF,  if  applied  to  the  existing  Link- 16  navigation  solution. 


The  purpose  of  Build_RF_Results_Data  is  to  package  the  error  estimates  of  the  DGPS 
RF  Kalman  Filter  for  transfer  to  the  Link- 16  OCP.  Note  that  this  function  exists  only  for  the 
Enhanced  Version  4.0  of  the  DGPS  algorithm. 
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4.5  Laboratory  Testing  Requirements  for  DGPS  RF  Algorithm-TATS  and 
Linkl6  OOP  Design  Modifications 


The  FY04  plans  for  the  DGPS  RF  project  provide  for  laboratory  testing  of  a  fully 
integrated  version  of  the  algorithm  within  the  Link- 16  Operational  Computer  Program  within  an 
actual  terminal.  The  test  bed  which  shall  be  utilized  for  this  activity  is  BAE  SYSTEMS 
Terminal  ATP  Test  Set  (TATS),  which  has  served  as  a  production  test  facility  in  several  versions 
over  the  past  twenty  years.  The  FY04  schedule,  beginning  in  October  2003  is  nine  months  in 
duration,  which  is  relatively  short  for  the  tasks  at  which  require  significant  modifications  to  both 
the  TATS  and  Link- 16  operational  software.  In  order  to  provide  a  level  of  risk  reduction  for  this 
activity,  advanced  design  and  planning  for  both  areas  was  scheduled  as  part  of  the  FY03 
activities.  The  purpose  of  this  section  is  to  summarize  the  work  performed  to  date  in  preparation 
for  the  FY04  activities. 


LINK  16  TERMINAL  UNDER  TEST 


•  REAL  DISPLAY  OF 
NAV  &  RF  RESULTS 


REFINEMENT  FILTER 
LINK  16  MESSAGES  - 
PSEUDORANGE/ 
EPHEMERIS  DATA 


Figure  4.5-1:  DGRF  Version  2.0  Operational  Environment 


The  operational  environment  for  the  planned  laboratory  testing  is  centered  about  the 
Terminal  ATP  Test  Set  -  TATS  (Figure  4.5  -  1),  on  which  the  modified  terminal  will  be 
exercised.  As  always,  the  task  of  the  TATS  will  be  to  replicate  at  both  RF  and  host  terminal 
interfaces,  exactly  the  data  transfer  in  both  format  and  medium  that  the  terminal  requires  for 
operation.  In  addition  to  the  currently  operational  Link-16  host  and  RF  interfaces,  the  TATS 
must  be  adapted  to  provide  the  following  capabilities  required  for  DGPS  RF  operation  that  do 
not  currently  exist: 

(1)  Replication  of  the  output  of  a  functional  GPS  receiver,  including  simulated 

pseudorange  measurements  and  ephemeris  data  characteristic  of  a  constellation  of 
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GPS  satellites  in  elliptical  orbit,  and  provided  to  the  terminal  via  the  host  1553 
interface. 

(2)  Generation  of  Master  Message  traffic  provided  via  the  terminal  RF  interface  which 
incorporates  master  navigation  data  and  simulated  pseudorange  data  measured  at  the 
master’s  true  position. 

(3)  Additional  input  data  representing  DGPS  operator  control  commands,  and  new  DGPS 
RF  output  data  and  status  needed  for  data  reduction  and  analysis 

The  new  operational  DGPS  RF  source  code  will  be  embedded  within  the  Link- 16  operational 
software,  and  wilt  need  to  interface  with  specific  portions  of  that  code  to  obtain  data  required  for 
its  operation.  The  general  requirements  listed  above  may  be  broken  down  into  subtasks  for 
both  the  TATS  Operational  Software  and  the  Link-16  OCP,  which  are  presented  below: 

Test  Set  (TATS)  Software  Required  Modifications: 

(a)  Inclusion  of  three  new  operator  control  inputs  which  invoke  the  operational  modes 
of  the  DGPS  algorithm:  (1)  RF_Enable ,  which  enables  operation  of  the  DGPS  RF 
Algorithm,  (2)  RF_OPR_SW,  which  represents  an  operator-derived  input 
commanding  algorithm  reinitialization,  (3)  MS_IND,  the  Master/Slave  Designator. 
All  inputs  to  be  provided  via  the  host  1553  MUX  input  at  times  specified  via 
initialization  data. 

(b)  Inclusion  of  a  test  cycle  parameter  DGPS_KAL_CYCLE,  which  will  specify  the 
Kalman  Cycle  rate  of  the  DGPS  algorithm.  This  value  may  take  on  the  values  of 
1,2,  or  4  Hz,  to  be  provided  via  the  host  1553  MUX  input.  This  input  to  be  required 
at  startup  only. 

(c)  Inclusion  of  a  (precomputed)  real  matrix  of  dimension  30  x  23  containing  the 
satellite  constellation  ephemeris  data  (EPHEM).  This  data  to  be  provided  via  the 
host  1553  MUX  input  at  startup  only. 

(d)  Inclusion  of  the  GPS  satellite  pseudorange  data  (SELF_GPS_DATA)  representative 
of  the  measurements  taken  at  the  position  of  the  slave  (self)  at  measurement  times. 
This  data  to  be  provided  via  the  host  1553  MUX  input  at  the  same  rate  specified  in 
(b).  The  measured  GPS  pseudorange  data  shall  be  precomputed,  and  shall  be 
provided  as  a  data  file  to  the  TATS  for  application  as  above. 

(e)  Inclusion  of  the  Master  Reporting  Message  at  the  rate  selected  in  (b)  and  transmitted 
by  the  Test  Terminal  to  the  TUT  as  a  TADIL-J  message.  This  message  shall  contain 
the  master  platform  position  and  recorded  GPS  pseudorange  block  data.  These 
messages  shall  be  precomputed  and  stored  within  the  TATS  for  transmission  at  the 
appropriate  transmission  times. 

(f)  Generation  of  true  master  and  slave  position  solutions,  which  are  transferred  to  the 
TUT  via  the  1553  MUX  input.  Note  that  this  data  will  be  utilized  only  by  Version 
2.0  of  the  DGPS  RF  software  for  laboratory  usage  only,  and  will  be  used  for  post- 
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test  data  reduction  only.  This  data  shall  be  provided  at  a  rate  of  once  per  250 
milliseconds. 


Link- 16  OCP  Required  Modifications 

The  Link- 16  OCP  shall  require  the  following  additional  functionality  to  support  the 

implementation  and  testing  of  the  DGPS  RF  operation: 

(a)  Transfer  of  the  self-derived  GPS  pseudorange  data  and  ephemeris  data  read  via  1553 
MUX  to  the  Host  Interface  Processing  function. 

(b)  Transfer  of  the  true  self  and  master  navigation  data  blocks  (defined  in  paragraph 
4.4.2)  to  OCP  Interface  Processing  function 

(c)  Transfer  of  DGPS  RF  Control  Data,  provided  via  1 553  MUX  to  OCP  Interface 
Processing. 

(d)  Extraction  of  own  self-navigation  data,  computed  within  Link- 16  OCP  to  OCP 
Interface  Processing. 

(e)  Acceptance  of  RF  Performance  Data  from  Host  Interface  Processing  for  transfer  to 
host  via  1553  MUX  output. 

(f)  Acceptance  of  DGPS  RF  core-generated  Master  Message  for  transmission  via  Link- 
16.  (Done  only  when  designated  as  master  platform). 

Specific  details  of  each  of  these  requirements  for  both  the  TATS  and  Link- 16  OCP  are  presented 
in  subsequent  paragraphs. 
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4.5.1  DGPS  RF  Control  Inputs 

The  satisfaction  of  the  requirements  specified  in  (a)  and  (b)  for  the  TATS  -provided  input 
data  variables  RF_ENABLE,  RF_OPER_SW,  MS_IND,  and 

DGPS_KAL_CYCLE  requires  the  provision  of  a  DGPS_Control_Word  within  the  1553  MUX 
whose  fields  control  the  inputs  values  of  these  variables.  This  word  shall  be  provided  at  each 
MUX  cycle  (50  ms).  The  word  image  of  the  DGPS_ControLWord  shall  be  as  depicted  in  Figure 
4.5  —  2.  Note  that  only  the  initial  values  of  MS_IND  and  DGPS_KAL_CYCLE  shall  be  utilized 
by  the  program.  Any  subsequent  changes  to  these  variables  shall  be  ignored. 


Figure  4.5-2:  DGPS  RF  CONTROL  WORD 
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4.5.2  GPS  Constellation  Ephemeris  Data 

There  will  be  24  operational  GPS  satellites  at  any  given  time,  and  thus  a  full  expression  of  the 
total  ephemeris  data  will  require  a  matrix  of  dimension  24  x  23.  For  laboratory  purposes, 
however,  we  will  assume  that  the  full  number  of  orbiting  satellites  can  equal  30.  Therefore,  the 
ephemeris  data  which  will  be  required  to  be  transferred  from  the  TATS  to  the  TUT  via  the  1553 
MUX  will  be  of  dimension  30  x  23,  where  the  data  from  each  visible  satellite,  indexed  by  I,  will 
be  inputted  in  turn.  The  format  for  this  data  will  be  in  double  precision  floating  point,  and  will 
follow  the  following  order  (Table  4.5-1)  for  each  satellite,  designated  by  SV  #  I. 

The  values  for  this  data  shall  be  precomputed  and  shall  be  provided  to  the  TATS  as  a  data  file.  It 
is  required  that  this  data  be  provided  only  once  at  program  initiation. 


Ephemeris  Variable  No. _ Data  Description 


LSB 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 
23 


Satellite  Vehicle  No. 

Week  No. 

TGD(Group  Delay)  2'^* 

TOC(Clock  Correction)  2'* 

AF2  (Clock  Correction)  2'^^ 

AF 1  (Clock  Correction)  2^^ 

AF0(Clock  Correction)  2’^* 

Crs(Sine  Harmonic)  2'^ 

Delta  n(Mean  Motion  Diff.)  2"^^ 

31 

Mo(Mean  Anamaly)  2' 

Cuc(Amp.  Sine  Harmonic)  2'^^ 

Es(SateIlite  Eccentricity)  2'^^ 

Cus(Sine  Harmonic)  2'^^ 

Sqrt.  Minor  Axis  2  *^ 

Toc(Ref.Time  Ephemeris)  2* 

OQ 

Cic(Cosine  Harmonic)  2 

Ogao(Long.  Of  Ascending  Node)  2'^' 
Cis  (Amp.  Of  Sine  Harmonic)  2'^^ 

io  (Inclination  Angle)  2'^* 

Crc(Cos  Harmonic  Correction)  2'^ 

Omega(  Angle  of  Perigee)  2'^  * 

Odot(RateofRA)  2"^^ 

idot(Rate  of  Inclination  Ang.)  2^^ 


Table  4.5-1:  Ephemeris  Data  per  Visible  Satellite 
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4.5.3  GPS  Pseudorange  Data 

The  GPS  pseudorange  data  which  will  be  supplied  to  the  TATS  will  be  synthesized  data 
not  derived  from  an  actual  GPS  pseudorange  measurement  from  satellites  in  elliptical  orbits. 

The  data  synthesis  of  the  code  phase  measurements  must  take  into  account  the  variable  transit 
time  of  the  satellite  signals.  For  this  reason,  this  computation  will  require  an  iterative  algorithm, 
to  be  described  herein,  to  make  the  derived  measurements  compatible  with  the  measurement 
time,  referred  to  as  the  GPS  Predicted  Time  tPGPSTMl.  This  computation  shall  be  performed 
offline  from  the  TATS,  and  the  results  provided  as  a  data  file  which  shall  be  read  at  the  rate 
specified  (l,2,or  4Hz)  in  the  initialization  data.  The  GPS  pseudorange  data  shall  be  supplied  in 
blocks  whose  formats  are  derived  from,  but  are  not  identical  to  Canadian  Marconi 
NORTHSTAR  Output  Message  23.  The  primary  difference  between  Message  23  and  the  format 
specified  here  is  that  in  the  former  case,  the  pseudorange  measurements  provided  by  the  GPS 
receiver  are  expressed  in  units  of  code  phase  counts,  while  in  our  case,  the  pseudorange 
measurements  shall  be  converted  directly  to  meters. 

The  algorithm  for  generating  the  synthetic  pseudorange  measurement  is  based  upon  the 
standard  algorithm  for  computing  satellite  ECEF  positions,  which  has  been  summarized  in 
Figure  3.3.2  -  2  of  this  report,  except  that  no  measurements  are  required.  Instead,  we  must 
compute  the  coarse  time  of  transmission  (TC)  for  each  individual  satellite  measurement  by 
compensating  for  the  signal  time  of  transit  based  upon  the  true  ranges.  The  process,  in  summary 
is  as  follows: 

(a)  Begin  the  pseudorange  estimation  process  by  zeroing  the  variable  PR  which 
represents  the  estimated  pseudorange  variable. 

(b)  Compute  the  ECEF  position  of  the  affected  satellite  using  the  elliptical  model. 

(c)  Compute  the  pseudorange  estimate  in  meters  using  the  computed  range  difference 
between  satellite  and  platform  as  well  as  clock  bias  contributions,  if  necessary. 

(d)  Use  the  estimated  pseudorange  value  to  recompute  TC,  and  iterate. 

(e)  Stop  the  computation  when  pseudorange  value  differences  are  below  a  preselected 
value. 
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Iteration  # 

TC(Seconds)  Satellite  Number  ISVNO 

PR  (meters) 

1 

238487.000000071 

6 

22148112.1031953 

2 

238486.926121919 

6 

22148141.8754309 

3 

238486.926121819 

6 

22148141.8754863 

4 

238486.926121819 

6 

22148141.8754863 

5 

238486.926121819 

6 

22148141.8754863 

6 

238486.926121819 

6 

22148141.8754863 

7 

238486.926121819 

6 

22148141.8754863 

8 

238486.926121819 

6 

22148141.8754863 

9 

238486.926121819 

6 

22148141.8754863 

10 

238486.926121819 

6 

22148141.8754863 

Table  4.5-2:  Synthetic  Pseudorange  Estimate  Convergence 


As  noted  in  Figure  4.5  -2,  above,  the  algorithm  converges  within  three  iterations  to  high 
accuracy.  The  above  computation  has  been  performed  for  Satellite  No.  6,  and  indicates  the  rapid 
estimation  of  the  coarse  time  of  transmission  and  the  generated  value  of  pseudorange  (PR)  in 
meters.  The  algorithm  pseudocode  is  presented  in  Figure  4.5  -  4,  below. 


For  K  =  1,  24 

Compute  mean  motion 

DELN  =  EPHEM(K,9) 

mean  motion  difference  [semicircle/s] 

SAS  =  EPHEM(K, 14) 

Square  root  of  semi-major  axis  [m^l/2] 

AS  =  SAS^2 

Semi -major  axis 

N  =  DSQRT(MU/AS^3)  +  DELN 

Computed  mean  motion 

Confute  mean  anomaly 

MO  =  EPHEM{K, 10) 

Mean  anomaly  at  reference  time  [smcir] 

MK  =  MO  +  N*(TC  -  TOE) 

Mean  anomaly 

Solve  for  eccentric  anomaly 

E  +  MK  +  ES*SIN(EOLD)  [Newton-Raphson] 

ES  =  EPHEM(K,  12) 

Eccentricity 

EKNEW  =  MK 

Kepler's  equation  for  Eccen.  anomaly 

FOR  JX; 1:100  DO 

EKOLD  =  EKNEW 

EKNEW  =  MK  +  ES*SIN (EKOLD) 

END 

E  =  EKNEW 

Eccentricity  anomaly 

Confute  time  correction  term 

DEKTR  =  F*ES*SAS*SIN{E) 

Relativistic  correction  term 

AFO  =  EPHEM(K, 7) 

7  - 

AFl  =  EPHEM(K, 6) 

6 

AF2  =  EPHEM{K,5) 

5  - 

TGD  =  EPHEM(K,3) 

3  - 

TOC  =  EPHEM(K,4) 

4  - 
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DELT  =  AFO  +  AFl* (TC  -  TOC)  + 

Transit  time 

AF2* (TC  -  TOC) ^2  +  DELTR  -  TGD 

T  =  TC  -  DELT 

GPS  time  of  transmission  correction 

R  =  AS* (1.0  -  ES*SIN(E)) 

Satellite  average  radius  R 

Compute  satellite  true  anomaly,  NU 

NUM  =  SORT (1.0  -  ES*ES) *SIN(E) ) / 

Sin (true  anomaly) 

(1.0  -  ES*COS(E) ) 

DENOM  =  (COS(E)-ES)/(1.0-ES*COS{E)) 

Cos (true  anomaly) 

NU  =  ATAN2 (NUM,  DENOM) 

Four  quadrant  inverse  tangent 

W  =  EPHEM(K,21) 

Argument  of  perigee  [semicircle] 

PHI  =  NU  +  W 

Argument  of  latitude 

Compute  correction  terms  from  harmonic 

:s 

CUS  =  EPHEM(K, 13) 

Amplitude  of  sine  harmonic  correction 
term  to  the  argument  of  latitude  [rad] 

cue  =  EPHEM(K, 11) 

Amplitude  of  cos  harmonic  correction 
term  to  the  argument  of  latitude  [rad] 

CRS  =  EPHEM(K, 8) 

Amplitude  of  sine  harmonic  correction 
term  to  orbit  radius  [m] 

OMEGAO  =  EPHEM(K,17) 

Longitude  of  ascending  node  of  orbit 
plane  at  weekly  epoch 

CIS  =  EPHEM(K, 18) 

Amplitude  of  sine  harmonic  correction 
term  to  the  angle  of  inclination  [rad] 

CRC  =  EPHEM(K, 20) 

Amplitude  of  cos  harmonic  correction 
term  to  the  orbit  radius  [m] 

CIC  =  EPHEM(K, 16) 

Amplitude  of  cos  harmonic  correction 
term  to  the  angle  of  inclination  [rad] 

IOTA  =  EPHEM(K,19) 

Inclination  angle  at  reference  time 
[semicircle] 

IDOT  =  EPHEM(K,23) 

Rate  of  inclination  angle  [semicir/s] 

C2PHI  =  COS(2*PHI) 

Double  angle 

S2PHI  =  SIN(2*PHI) 

Second  harmonic  perturbations 

DELPHI  =  CUS*S2PHI  +  CUC*C2PHI 

Argument  of  latitude  correction 

DELR  =  CRS*S2PHI  +  CRC*C2PHI 

Radius  correction 

DELI  =  CIS*S2PHI  +  CIC*C2PHI 

Corrected  inclination 

PHI  =  PHI  +  DELPHI 

Corrected  argument  of  latitude 

R  =  R  +  DELR 

Corrected  radius 

IOTA  =  IOTA  +  DELI  +  IDOT* (T-TOE) 

Corrected  inclination 

OMEGAD  =  EPHEM(K,22) 

Rate  of  right  ascension  [semicircle/s] 

OER  =  OMEGAO  +  OMEGAD* (T-TOE)  - 

Corrected  longitude  of  ascending  node 

OMEGAE*T 

Confute  satellite  ECEF  vector  (meters) 
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ECEFXS(K)  =  R*COS(OER)*  COS (PHI ) -R*SIN (OER) *COS ( IOTA) *SIN (PHI) 
ECEFYS(K)  =  R*SIN(OER)*  COS (PHI) +R*COS (OER) *COS (IOTA) *SIN (PHI) 
ECEFZS(K)  =  R*SIN (IOTA) *SIN (PHI) 

Compute  Provisional  Pseudorange  Estimate 

PR  -  SQRT[(ECEFXS(K)-XP)^  +  (ECBFYS  (K) -YP)  (ECEFZS  (K) -ZP)  M 

ECEFYS(K)  =  R*SIN(OER)*  COS (PHI) +R*COS (OER) *COS (IOTA) *SIN( PHI) 
IF (CHANGE_IN_PR  >  LIM)  THEN 
GO  TO  5000 
END  IF 

END  FOR  _ _ _ 

Figure  4.5-3:  Generation  of  Synthetic  Pseudorange 
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4.5.4  Master  Reporting  Message  Characteristics 

The  Master  Reporting  message,  transmitted  via  the  TT  to  the  TUT  shall  be  a  Link-16  TADIL-J 
message,  designated  as  a  J28.7  message.  As  a  TADIL-J  message,  the  J28.7  shall  consist  of  an 
initial  word,  extension  word,  and  0  to  4  continuation  words,  depending  on  the  number  of 
satellites  observed  by  the  master  platform.  A  maximum  of  10  sets  of  satellite  IDs  and 
corresponding  pseudoranges ,  together  with  a  time  tag  and  master  platform  navigation  data  shall 
be  packaged  within  each  J28.7  message  transmitted.  The  number  of  continuation  words  required 
as  a  function  of  number  of  observed  satellites  shall  be  as  follows: 

Number  of  Observed  Satellites _ Number  of  Continuation  Words 

1  0 

2-3  1 

4-5  2 

6-8  3 

9-10  4 


Note  that  the  minimum  sustainable  satellite  count  to  assure  DGPS  operation  is  5,  so  that  there 
will  nearly  always  be  2  or  more  continuation  words  provided  in  each  J28.7  message.  A 
provisional  detailed  format  for  the  initial,  extension,  and  continuation  words  of  the  J28.7 
message  has  been  prepared  and  is  presented  in  Figure  4.5-4,  over  the  next  15  pages. 
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J28.7  MESSAGE  SUMMARY 

PURPOSE:  The  J28.7  Master  message  is  used  to  provide  pseudorange  data  for  up  to  10 
satellites  and  position  data  from  the  master  platform  to  the  slaves.  The  message  contains  the 
Master  platforms  latitude,  longitude,  altitude,  time  tag  of  Nav  solution,  up  to  10  pseudoranges  to 
satellites  and  the  associated  satellite  number.  The  message  will  be  transmitted  at  a  one  to  four 
Hz  rate  (rate  is  TBD).  The  amount  of  data  in  the  message  requires  that  some  of  the  data  be 
coded  to  reduce  word  size. 


The  data  will  be  coded  as  indicated  below. 


Data  Element 

#  BITS 

LSB 

RANGE 

Comments 

Satellite  Number 

5 

1 

0-24 

unsigned  integer 

Pseudorange 

by 

21 

11.6  ft 

10k  -  18k 

Range  is  offset 
10k  -  iinsigned 
integer 

Latitude 

24 

2.256  ft 

+90  deg 

signed  integer 

Longitude 

24 

4.512  ft 

0-360  deg 

unsigned  integer 

Altitude 

14 

6.1  ft 

-20k  -  +80k 

offset  by  20k 
unsigned  integer 

Number  of  Satellites 

4 

1 

0-10 

max  number  of 
pseudorages  in  a 
message  =  10 

Time  Tag 

24 

1 

0-11059199 

LSB  is  1  slot 
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DATA  ELEMENT  SUMMARY 


J28.7I 

DATA  ELEMENT _ #  BITS 

Word  Format  2 

Label,  TADIL  J  5 

Sub  label,  TADIL  J  3 

Message  Length  Indicator  3 

Number  of  Satellites  4 

Master  Latitude  24 

Master  Longitude  24 

Satellite  I's  Number  5 


DATA  ELEMENT 

J28.7E0 

i  BITS 

Word  Format 

2 

Master  Altitude 

14 

Time  Tag 

24 

Satellite  1' s 

Pseudorange 

21 

Satellite  2's 

Number 

5 

Spare 

4 

J28 .7C1 

DATA  ELEMENT 

#  BITS 

Word  Format 

2 

Continuation  Word  Label 

5 

Satellite  3's  Number 

5 

Satellite  4's  Number 

5 

Satellite  5's  Number 

5 

Satellite  6's  Number 

5 

Satellite  2's  Pseudorange 

21 

Satellite  3's  Pseudorange 

21 

Spare 

1 
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J28.7C2 

DATA  ELEMENT _ #  BITS 


Word  Format 

2 

Continuation  Word  Label 

3 

Satellite 

4' s 

Pseudorange 

21 

Satellite 

5's 

Pseudorange 

21 

Satellite 

7's 

Number 

5 

Satellite 

8's 

Number 

5 

Satellite 

9's 

Number 

5 

Spare 

6 

J28.7C3 

DATA  ELEMENT 

it  BITS 

Word  Format 

2 

Continuation  Word  Label 

5 

Satellite  6's  Pseudorange 

21 

Satellite  7's  Pseudorange 

21 

Satellite  8's  Pseudorange 

21 

J28.7C4 

DATA  ELEMENT 

«  BITS 

Word  Format 

2 

Continuation  Word  Label 

5 

Satellite  9's  Pseudorange 

21 

Satellite  10 's  Pseudorange 

21 

Satellite  10 's  Number 

5 

Spare 
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J2.0  TRANSMIT/RECEIVE  RULES 


TITLE:  MASTER  Message 


TRANSMIT  RULES 
1. 


RECEIVE  RULES 
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WORD  DESCRIPTION 


WORD  NUMBER;  J28.7C4 

WORD  TITLE:  MASTER  MESSAGE  CONTINUATION  WORD  4 


REFERENCE 

BIT 

# 
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DATA  FIELD  DESCRIPTOR 

POSITION 

BITS 

**** 

*** 
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Figure  4.5-4:  J28.7  Structure  and  Format 
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5.  Results  and  Discussion  -  Phase  1  Activities 
October  2002  -  September  2003 

BAE  SYSTEMS  believes  that  the  principal  goals  of  this  phase  of  the  project  were 
successfully  achieved.  These  goals  centered  around  the  development  of  a  robust,  reliable 
algorithm  capable  of  achieving  extremely  precise  relative  positioning  and  time  synchronization. 
During  the  course  of  this  work,  a  detailed  real-time  design  for  the  algorithm  operational  software 
was  developed  and  documented.  Finally,  extensive  long-lead  design  for  support  of  the  planned 
laboratory  demonstration  was  accomplished,  which  will  assure  a  smooth  transition  to  the  next 
project  phase.  The  studies  performed  in  this  project  phase  resulted  in  many  lessons  learned, 
which  contributed  to  a  high  degree  of  confidence  in  the  integrity  of  the  basic  design.  A  brief 
overview  of  the  project  highlights  and  the  most  important  insights  that  were  achieved  follows. 


5.1  Validity  of  Fundamental  Error  Model 

The  fundamental  error  modeling  of  the  Link-16  position  errors  was  predicated  on  the 
assumption  that  these  terms  are  slowly  varying  as  compared  with  the  amount  of  state  information 
provided  via  the  GPS  pseudorange  data.  The  simulations  performed  as  part  of  Test  Bed  1  and 
Test  Bed  2  studies  (Paragraphs  4.2  and  4.3)  verified  these  assumptions  in  all  cases  studied.  In 
particular,  the  application  of  the  Link-16  Navigation  Simulator  for  Test  Bed  2  to  represent  the 
dynamics  of  the  navigation  error  model  proved  the  success  of  the  DGPS  RF  algorithm  under 
realistic  tactical  scenarios. 


5.2  Open  vs.  Closed  Loop  Operation  -  Solution  Stability  Issues 

The  studies  performed  during  Test  Bed  1  operation  uncovered  the  potential  of  solution 
unstability  when  operating  in  closed  loop  mode,  that  is  applying  the  corrections  derived  by  the 
DGPS  algorithm  to  the  Link- 16  navigation  solution  and  zeroing  the  state  elements  thereafter. 
(Paragraphs  4.2.1  -  4.2.2)  In  all  cases  studied,  this  resulted  in  solution  divergence,  sometimes 
after  hundreds  of  seconds  of  apparently  stable  operation.  When  DGPS  RF  errors  were  kept 
separate  from  the  Link-16  navigation,  the  instability  disappeared  and  reliable  operation  was 
maintained  indefinitely  in  all  scenarios. 

The  instability  noted  in  closed  loop  operation  does  not  mean  that  a  fully  integrated  closed 
loop  solution  cannot  be  achieved.  However,  such  a  solution  would  require  extensive 
modifications  to  the  Link- 16  algorithm  to  maintain  the  assumptions  of  Kalman  optimality  that 
were  violated  by  a  simple  reset  of  error  terms  used  in  these  studies.  There  appears  to  be  no 
reason  why  the  full  benefits  of  the  algorithm  cannot  be  realized  in  open  loop  operation,  so  there 
was  no  urgency  to  refine  the  closed  loop  solution  as  described  above.  Nevertheless,  we  expect  to 
revisit  this  issue  in  the  future  to  determine  if  still  further  improvements  can  be  achieved  by 
tighter  integration  of  the  two  algorithms. 
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5.3  Sensitivity  to  Update  Rate 

A  critical  lesson  learned  during  these  studies  is  that,  within  the  range  of 
0.25  and  4  Hz  rate  of  pseudorange  observations,  the  steady  state  errors  remain  virtually  constant. 
(Paragraph  4.2.6)  Of  course,  more  rapid  convergence  to  the  steady  state  values  is  noted  at  the 
higher  observation  rates.  At  4  Hz,  for  example,  steady  state  is  achieved  within  5  to  10  seconds 
of  algorithm  initiation  while  at  the  1  Hz  rate,  such  convergence  may  require  50  to  60  seconds. 
Operationally,  we  would  prefer  to  use  the  lowest  rate  possible  consistent  with  solution  steady 
state  accuracy,  since  the  higher  rates  impact  the  usage  of  Master  Messages  and  expend  Link- 16 
bandwidth  at  a  higher  than  desired  level.  A  compromise  value  would  seem  to  be  the  1  Hz  rate, 
which  is  the  planned  rate  which  we  hope  to  use  during  theTATS  laboratory  demonstration. 


5.4  Sensitivity  to  Link-16  Navigation  Errors 

One  of  the  gratifying  observations  made  during  these  studies  was  that  there  was  virtually 
no  sensitivity  to  the  magnitude  of  the  Link- 16  navigation  errors  except  at  levels  which  are  far 
beyond  those  expected  in  Link- 16  hybrid  navigation.  (Paragraph  4.2.5)  It  was  not  until  a  level  of 
more  than  750  feet  per  axis  that  unstable  operation  was  noted.  This  was  not  very  surprising, 
since  it  is  well  known  that  Extended  Kalman  Filters  usually  have  convergence  problems  when 
errors  exceed  some  critical  level.  The  fact  that  the  DGPS  algorithm  would  likely  never  be 
exposed  to  errors  even  a  quarter  as  large  as  these  critical  levels  indicates  that  it  will  function  well 
in  nearly  all  practical  environments. 


5.5  Effect  of  Velocity  States  on  Algorithm  Performance 

At  the  inception  of  this  study,  provision  was  made  for  the  inclusion  of  three  velocity  error 
states  within  the  DGPS  RF  Kalman  Filter  to  investigate  their  effectiveness  in  cases  where 
significant  unmodelled  velocity  existed  in  the  navigation  solution.  (Paragraph  4.2.4).  Two 
important  conclusions  were  reached  when  testing  the  effectiveness  of  these  state  variables:  (a) 
When  used  in  closed  loop  operation,  their  presence  within  the  filter  proved  to  be  destabilizing, 
and  resulted  in  highly  oscillatory  performance  prior  to  solution  divergence,  and  (b)  In  open  loop 
operation  resulting  in  stable  performance,  there  was  virtually  no  effect  on  accuracy  whether  or 
not  the  velocity  states  were  used.  The  clear  conclusion  is  that  these  terms  are  best  deleted  from 
the  filter  design  since  they  provide  no  positive  effect  in  stable  solutions,  and  are  harmful  in 
solutions  tending  to  instability. 


5.6  Clock  Bias/Frequency  Estimation  Performance 

The  precision  navigation  goals  inherent  in  the  DGPS  RF  algorithm  make  it  mandatory  to 
estimate  residual  GPS  time  and  frequency  errors  at  the  same  time  that  we  estimate  the  position 
errors.  Although  a  typical  GPS  time  offset  will  normally  be  relatively  small,  on  the  order  of  tens 
of  nanoseconds,  at  most,  this  term  must  be  calibrated  out  by  the  filter.  Likewise,  the  relative 
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frequency  drift  of  the  GPS  oscillators  must  be  estimated  to  assure  good  drift  characteristics  in 
periods  of  GPS  observation  interruption.  The  tests  conducted  using  Test  Bed  2  assumed  both 
time  and  frequency  errors  at  least  one  order  of  magnitude  more  than  would  be  normally 
expected,  with  excellent  results  (Paragraph  4.3.5).  For  these  tests,  a  bias  term  of  200 
nanoseconds  and  frequency  drift  of  10  ns/seconds  was  assumed.  Filter  results  calibrated  bias  to 
fractions  of  a  nanosecond,  and  frequency  drift  to  well  under  one  nanosecond  per  second.  No 
attempt  to  exceed  these  initial  errors  was  made,  but  there  is  no  reason  to  suspect  that  any 
reasonable  limit  applies,  as  long  as  initial  covariance  estimates  exceed  these  errors. 


5.7  Solution  Sensitivity  to  Kalman  Filter  Process  Noise 

The  addition  of  process  noise  is  a  vital  part  of  the  filter  design  to  account  for  unmodelled 
error  sources  which,  if  not  compensated  for,  could  cause  error  terms  to  exceed  covariance  values. 
For  a  design  of  this  kind,  where  many  satellites  are  processed  in  each  filter  update  cycle,  one 
would  expect  that  higher  levels  of  process  noise  would  tend  to  be  helpful  in  keeping  the  filter 
gains  from  dropping  to  undesirably  low  levels.  This  indeed  turns  out  to  be  the  case.  (Paragraph 
4.2.9).  When  very  low  levels  of  process  noise  (i.e.  less  than  1  foot  per  axis  per  cycle)  are  added, 
the  filter  still  converges,  but  tends  to  do  so  sluggishly.  By  comparison,  addition  of  5-10  foot 
process  noise/cycle  results  in  rapid  and  consistent  convergence  of  error  terms.  The  final  value 
selected  for  position  process  noise  was,  in  fact  10  feet  per  axis. 


5.8  Solution  Sensitivity  to  Low  Pass  Filtering 

The  error  terms  estimated  by  the  DGPS  RF  filter  are,  in  fact,  the  residual  errors  for  the 
Link- 16  hybrid  inertial  navigation.  In  normal  Link- 16  navigation,  the  application  of  position 
updates  caused  by  receipt  of  PPLI  messages  will  result  in  step  changes  in  estimated  position 
error .  When  comparing  DGPS  RF  estimates  for  these  errors,  error  spikes  coinciding  with  the 
Link-16  navigation  filter  are  noted.  (Paragraph  4.3.2)  The  actual  position  errors  of  the  two 
platforms  are,  in  fact,  smoothly  varying  terms.  While  each  spike  is  eliminated  within  a  single 
update  cycle,  these  discontinuities,  it  is  desirable  to  low-pass  process  these  errors  with  a  separate 
LP  filter  having  time  constant  on  the  order  of  a  few  seconds.  These  error  graphs  are  improved 
representatives  of  the  true  state  of  the  error  estimation  process,  and  a  low  pass  filtering  process 
was  therefore  included  within  the  final  software  design  for  this  algorithm. 


5.9  Sensitivity  to  Number  of  Satellites  Processed 

Normal  operation  of  the  DGPS  RF  algorithm  will  process  pseudoranges  from  as  many 
satellites  as  are  received  which  lie  at  least  five  degrees  above  the  horizon.  Typical  satellite 
counts  in  these  cases  range  from  8-11.  However,  it  is  possible  to  conceive  of  partial  GPS 
januning  circumstances  where  the  estimator  may  be  forced  to  operate  with  a  number  of  satellites 
smaller  than  these  numbers.  (Paragraph  4.3.4)  Hence,  a  special  test  was  performed  which 
steadily  reduced  the  number  of  satellites  to  investigate  the  performance  deterioration,  if  any.  The 
result  of  this  test  was  that  there  was  virtually  no  degradation  of  performance  when  satellites 
processed  were  reduced  to  six.  Reducing  the  number  to  five  resulted  in  brief  spikes  up  to  10 
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feet,  which  were  quickly  reduced  by  further  processing.  It  was  only  when  the  number  of 
satellites  was  reduced  to  four  that  the  solution  was  observed  to  collapse.  It  should  be  noted  that 
there  was  no  specific  selection  criteria  for  satellites  used  within  this  test,  with  the  deleted 
satellites  simply  taken  from  the  end  of  the  satellite  processing  list.  It  is  possible  that  the  four 
satellite  case  failed  simply  because  the  satellites  remaining  failed  to  provide  observational  data  in 
orthogonal  directions.  Whatever  the  case  was  for  this  test,  the  algorithm  itself  demonstrated 
remarkable  robustness  as  to  the  number  of  satellites  required  for  acceptable  levels  of  operation. 


5.10  Real-Time  Software  Design  for  the  DGPS  RF  Algorithm 

The  generation  of  a  modular,  robust  real  time  implementation  of  the  DGPS  RF  algorithm 
was  a  prime  goal  of  this  phase  of  the  project.  The  resulting  design  (Paragraph  4.4)  is  the  result 
of  these  efforts.  The  differing  environments  for  testing  of  this  algorithm  (PC,  Laboratory,  and 
Airborne  Testing)  required  the  development  of  no  less  than  three  different  variants  (Versions  1, 
2,  and  3)  which  were  specifically  designed  for  operation  in  their  respective  venues.  (Note:  A 
fourth  version  has  been  proposed,  as  well,  which  would  add  the  capabilities  of  the  Atmospheric 
Refinement  Filter,  as  discussed  in  Paragraph  6.0) 

The  key  to  minimum  redesign  of  the  DGPS  RF  operational  software  was  to  concentrate 
the  key  processing  requirements  within  five  “core”  elements,  namely: 

(a)  RF  Executive  Control 

(b)  RF  Source  Data  Processing 

(c)  RF  Kalman  Processing 

(d)  Build  Master  Message 

(e)  Build  RF  Results  Data 

These  elements  require  virtually  no  modification  for  all  program  versions.  The  primary 
differences  in  the  operational  software  reside  within  the  two  interface  modules,  namely: 

(f)  OCP  Interface  Processing 

(g)  Host  Interface  Processing 

The  differences  in  these  two  versions  are  due  primarily  to  the  change  from  a  simulator 
representation  (LNS)  of  the  Link- 16  navigation  utilized  in  Version  1,  to  the  interface  with  a 
working  Link- 16  terminal  OCP  for  Version  2.  Little  modification  will  be  required  to  move  to 
Version  3,  the  airborne  test  software,  and  these  changes  will  depend  primarily  on  the  specific 
GPS  receiver  which  will  be  selected  for  these  test  activities. 

The  success  of  this  software  design  may  be  judged  by  the  fact  that  all  Test  Bed  2 
simulation  results  presented  in  this  report  were  generated  with  the  software  build  to  Version  1 
specifications. 
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5.11  Preparation  for  Laboratory  Testing  -  Modification  of  TATS  and  Link- 
16  OCP. 

A  significant  amount  of  time  was  expended  during  phase  1  of  this  project  in  initiating 
design  work  for  the  Link- 16  OCP  as  well  as  the  Terminal  ATP  Set  to  prepare  for  the  phase  2 
laboratory  testing.  In  the  case  of  the  TATS,  specific  modifications  were  identified  covering  new 
input  data  streams  required  to  represent  the  GPS  pseudorange  measurements,  ephemeris  data, 
and  the  J28.7  master  message  formats.  None  of  these  inputs  are  currently  in  use  for  the  TATS 
unit.  However,  the  time  sequencing  of  each  of  these  streams  is  essentially  predetermined,  since 
they  will  be  functions  of  aircraft  trajectories  and  the  satellite  ephemeris  data.  Therefore,  it  will 
be  possible  to  precompute  approximately  90%  of  all  of  this  data.  The  effect  of  this  is  to 
eliminate  a  great  deal  of  expensive  redesign  for  the  TATS  software.  We  need  simply  to  assure 
that  the  appropriate  message  data  and  measurements  are  “metered  out”  within  the  TATS 
according  to  the  scenario  selected.  This  will  have  the  result  of  greatly  reducing  cost  and  risk  for 
modifying  the  TATS  software  to  reconfigure  it  for  the  laboratory  testing. 

The  majority  of  the  labor  hours  scheduled  to  be  expended  within  phase  two  deal  with  the 
reconfiguration  of  the  Link- 16  OCP  software  to  accommodate  the  DGPS  RF  algorithm.  This 
will  involve  a  degree  of  refinement  and  repackaging  of  the  core  and  interface  modules  described 
in  Paragraph  4.4,  and  listed  in  Appendix  A  in  order  to  assure  compatibility  of  data  interfaces 
with  the  existing  OCP  design.  We  have  taken  great  pains  to  simplify  the  OCP  and  Host  interface 
requirements.  In  particular,  the  data  transfer  of  navigation  data  from  the  Link- 16  hybrid 
navigation  is  effectively  “one  way”.  That  is  to  say  that  no  direct  feedback  into  the  complex 
navigation  software  of  DGPS  RF  results  is  required,  or  even  allowed.  The  incorporation  of  the 
DGPS  RF  results  will  be  performed  within  the  host  software,  with  no  disruption  of  the  hybrid 
navigation  within  the  terminal.  Once  again,  a  precise  and  well  defined  interface  design  will  pay 
large  dividends  in  minimizing  risk  and  cost  for  the  upcoming  software  laboratory  demonstration. 
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6.  Recommendations 

The  results  of  this  study  to  date  indicate  that  the  expected  performance  levels  of  the 
DGPS  RF  algorithm  are  indeed  achievable.  The  goals  of  better  than  1  meter  relative 
performance  in  position,  0.1  ft/sec  in  velocity,  and  time  synchronization  relative  to  master  of  1 
nanosecond  or  better  have  been  achieved  in  Version  1.0  in  a  laptop/PC  environment.  It  is 
expected  that  the  laboratory  demonstration  of  the  DGPS  RF  algorithm  using  a  Link- 16  terminal 
in  conjunction  with  the  Terminal  ATP  Test  Set  during  October  2003  through  May  2004  will 
confirm  these  performance  levels. 


6.1  Proposed  Airborne  Flight  Testing  of  DGPS  RF  Version  3.0 

Because  of  the  modular  structure  of  the  DGPS  RF  operational  code,  few  modifications 
will  need  to  be  made  to  achieve  Version  3.0  capability,  that  is,  to  generate  a  code  version  capable 
of  airborne  flight  testing  using  actual  aircraft  and  GPS  receiver  assets.  The  only  code  changes 
required  will  be  to  modify  Host  Interface  Processing  to  accommodate  the  precise  format  of  the 
pseudorange  and  ephemeris  data  provided  by  the  GPS  receiver  selected  for  testing.  Because  of 
the  extremely  accurate  positioning  provided  by  the  algorithm,  an  equally  accurate  position 
reference  must  be  provided  to  measure  true  system  performance  where  two  or  more  aircraft  are 
equipped  with  DGPS  RF  modified  terminal  assets.  It  is  clear  that  only  an  external  Differential 
GPS  navigation  reference  can  provide  these  levels  of  accuracy. 

BAE  has  had  experience  using  Differential  GPS  references  in  tests  performed  at  Wallops 
Island  in  conjunction  with  Naval  Weapons  Center,  Dahlgren  Va  personnel  for  Link-16  Sensor 
Registration  tests  performed  in  support  of  the  Single  Integrated  Air  Picture  (SIAP)  In  these 
tests,  performed  during  2001  (Figure  6-1),  three  test  aircraft  were  flown  in  the  vicinity  of  the 
Wallops  Island  SPY-1  radar  for  the  purpose  of  testing  sensor  registration  algorithms.  A  key 
component  of  the  test  was  a  special  aircraft  equipped  with  Differential  GPS  navigation  which 
served  as  a  reference  for  the  estimated  aircraft  positions  computed  by  the  SPY-1  radar  when 
corrected  for  bias  errors  by  the  sensor  registration  algorithm.  The  equipment  carried  by  this  test 
aircraft  has  an  estimated  position  error  in  the  vicinity  of  1  meter,  which  is  within  the  range  that 
we  would  be  seeking  for  any  flight  test  of  the  DGPS  RF  algorithm. 
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Figure  6-1 


A  flight  test  community  suitable  for  our  proposed  test  could  use  two  aircraft  playing  the 
roles  of  master  and  slave  platforms.  Alternatively,  and  less  expensive  to  conduct,  the  master 
could  be  played  by  a  ground  station  located  at  a  surveyed  position  on  the  earth.  (Figure  6-2), 
while  the  slave  would  still  require  a  fully  integrated  pallet  containing  INS,  Link-16,  GPS 
receiver,  and  an  independent  differential  GPS  position  reference  and  a  flight  recorder  to  capture 
test  data.  The  major  expenses  for  such  a  test  would  be  the  construction  of  the  test  pallet  and,  of 
course  the  costs  incidental  to  the  aircraft  itself  (fuel,  crew,  etc.).  One  possibility  to  minimize 
these  costs  could  be  to  use  an  aircraft  with  Link- 16  (MIDS)  already  integrated,  such  as  the  F/A- 
18,  but  such  an  aircraft  would  need  to  be  equipped  with  a  flight  recorder  and  have  the  GPS 
interface  modified  to  allow  pseudorange  measurements  to  be  passed  via  the  1553  MUX  input. 
Detailed  tradeoffs  of  cost  and  logistics  will  be  required  to  select  the  optimum  test  asset  for  this 
exercise. 
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Figure  6-2 


6.2  Integration  of  DGPS  RF  With  Atmospheric  Refinement  Filter 

It  is  a  well  known  fact  that  uncertainties  in  atmospheric  refraction  leading  to  unmodelled 
PPLI  Time  of  Arrival  errors  represent  the  largest  single  component  of  Link- 16  navigation  errors. 
For  this  reason,  BAE  SYSTEMS,  under  ONR  sponsorship,  has  initiated  a  study  to  apply  sensor 
registration  methodology  to  produce  real  time  estimates  of  refraction  model  parameters.  The 
resulting  algorithm,  designated  as  the  Atmospheric  Filter  (AF),  has  been  shown  to  produce 
extremely  accurate  estimates  of  true  range  between  Link- 16  transmitter  and  receiver,  in  the  range 
of  one  to  two  meters.  The  existing  constant  two-parameter  refraction  model  now  implemented  in 
Link-16  averages  10  or  more  meter  errors  in  range  estimates  for  short  range,  and  can  suffer 
errors  of  more  than  100  meters  for  ranges  in  excess  of  150  kilometers  due  to  atmospheric 
variation. 

Since  both  the  Atmospheric  Filter  and  the  DGPS  RF  have  as  their  ultimate  purpose  the 
improvement  of  community  navigation,  these  algorithms  should  be  viewed  as  complementary  in 
nature.  In  particular,  the  E)GPS  RF  can  provide  the  extremely  accurate  true  range  estimate 
needed  for  the  AF,  while  the  AF  range  quality  can  help  to  maintain  precision  navigation 
accuracy  even  during  periods  of  GPS  jamming  or  interruption,  once  the  atmospheric  calibration 
has  been  accomplished.  The  DGPS  RF  algorithm  is  scheduled  for  laboratory  integration  during 
phase  2  of  the  project  commencing  in  October  2003.  This  may  be  viewed  as  an  opportunity  to 
also  perform  laboratory  validation  of  the  AF  algorithm  as  well.  Paragraph  4.5  of  this  report 
introduced  the  modifications  required  to  exercise  the  DGPS  algorithm  on  the  TATS  equipment. 
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including  provision  of  the  GPS  satellite  observations.  Compared  to  these  efforts,  the  addition  of 
a  true  atmospheric  model  needed  to  exercise  the  AF  would  be  a  relatively  minor  addition  to  the 
tasks  already  scheduled  for  the  TATS.  Similar  modifications  to  the  Link- 16  OCP  to  support  the 
AF  algorithm  are  likewise  simpler  than  their  DGPS  counterparts,  since  no  external  observations 
are  required  for  the  AF  algorithm.  This  algorithm  requires  only  the  availability  of  the  existing 
PPLI  message  traffic,  which  is  now  supported  by  the  TATS  architecture. 


7.  Conclusions 

The  results  presented  in  detail  in  paragraph  4.3  indicate  that  the  goals  assumed  at  the 
beginning  of  this  project  have  indeed  been  realized.  The  clear  result  of  this  study  is  that  we  have 
succeeded  in  demonstrating  the  practicality  of  a  software  algorithm  capable  of  refining  mobile 
community  navigation  and  time  synchronization  to  levels  that,  to  the  author’s  knowledge,  have 
not  previously  been  demonstrated  without  the  prior  establishment  of  a  surveyed  reference  point, 
as  in  conventional  differential  GPS  operation.  The  DGPS  RF  algorithm  has  been  proven  to 
provide  a  relative  positioning  accuracy  between  a  platform  and  a  designated  mobile  master 
reference  of  well  under  one  meter,  as  well  as  a  relative  time  synchronization  of  one  nanosecond 
or  better.  This  capability  has  been  achieved  using  existing  Link- 16  capabilities  combined  with 
processing  of  pseudorange  measurements  from  the  GPS  satellite  community.  Aside  from  the 
necessity  of  providing  these  GPS  measurements  to  the  Link- 16  terminal,  all  of  the  necessary 
modifications  reside  exclusively  in  the  software  algorithm  designed  and  developed  during  the 
course  of  this  project.  The  fundamental  basis  of  this  technique  is  to  exploit  the  robust  and 
reliable  hybrid  navigation  processing  that  currently  exists  in  each  and  every  Link- 16  terminal, 
and  remove  the  slowly  varying  errors  that  result  through  GPS  psuedorange  measurements. 

The  implications  of  this  capability  are  significant  to  US  warfighting  ability  in  at  least 
two  areas,  namely  (a)  Cooperative  Tactics  for  Hostile  Emitter  Location,  and  (b)  Remote  Time 
Transfer  among  mobile  participants.  We  consider  each  of  these  areas  in  turn,  below. 


7.1  Cooperative  Tactics  for  Hostile  Emitter  Location 

Rapid  and  effective  localization  of  hostile  emitters  remains  a  critical  operational 
requirement  for  many  tactical  missions.  The  difficulty  of  geolocation  of  hostile  emitters  with  a 
single  search  platform  is  well  known.  A  single  aircraft  must  fly  a  lengthy  base  leg  to  develop 
significant  target  observability,  and  the  time  required  to  geolocate  a  target  at  a  range  of,  say, 
fifty  miles,  can  often  be  measured  in  hundreds  of  seconds.  By  comparison,  the  use  of  multiple 
aircraft  well  correlated  in  position  and  time  which  are  sharing  measurement  data  can  reduce  the 
time  for  geolocation  to  less  than  ten  seconds  or  better.  (Figure  7-1).  The  application  of  the 
DGPS  RF  algorithm  technology  to  this  mission  is  self-evident.  Residual  geolocation  errors  of 
emitters  will  always  be  measured  in  multiples  of  the  relative  positioning  accuracy  of  the 
measurement  platforms.  The  benefits  of  mobile  members  whose  relative  positioning  errors  are 
less  than  a  meter  means  that  targets  can  be  located  to  comparable  accuracy  through  a  variety  of 
sensor  measurements.  Phase  interferometry  is  one  such  method.  Delta  Frequency  and  Time 
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algorithms  provide  still  another  option  for  precise  geolocation.  All  require  the  utmost  in  position 
correlation  between  measurement  platforms.  As  part  of  the  architecture  studies  performed  by 
BAE  SYSTEMS  on  the  DARPA-sponsored  AT-3  emitter  geolocation  study  in  2001,  the  DGPS 
RF  algorithm  was  embedded  within  the  sensor  package  to  provide  necessary  navigation  and  time 
synchronization  precision  (Figure  7-2) 

The  benefits  of  the  DGPS  RF  Algorithm  to  the  emitter  location  problem  are  not 
restricted  to  geolocation.  Many  sophisticated  target  identification  algorithms  also  exist  which 
depends  on  exquisitely  accurate  time  synchronization  between  multiple  platforms.  This  synch  is 
necessary  to  classify  the  precise  radar  type,  and  indeed  provide  a  signature  of  the  individual 
emitter  via  “pulse  fingerprints”  which  include,  for  example,  pulse  rise  time.  Relative 
synchronization  of  collector  platforms  to  nanosecond  level  is  a  vital  component  of  this 
processing.  DGPS  RF  is  designed  to  provide  exactly  this  capability. 


7.2  Remote  Time  Transfer  Applications 

The  US  Navy  recognizes  the  importance  of  maintenance  of  precise  timing  within 
individual  ships  and  task  forces  for  the  purpose  of  synchronization  of  various  communication, 
navigation,  and  fire  control  units.  A  system  engineering  team  (SET)  designated  as  Common 
Time  Reference  (CTR)  was,  in  fact  established  in  1998,  to  specifically  explore  this  capability. 
The  CTR  SET  was  absorbed  by  the  SIAP  organization  in  2001 .  The  CTR  SET  established 
requirements  for  both  intraplatform  and  interplatform  transfer  of  precision  time  references.  A 
key  requirement  identified  by  the  CTR  SET  is  the  ability  to  achieve  extremely  precise  time 
transfer  from  a  remote  standard  time  reference  to,  say,  a  fleet  at  sea. 

The  CTR  Draft  Requirements  Document  states  that  a  passive  (i.e.  non  transmitting 
platform)  is  capable  of  inheriting  UTC  time  to  within  50  nanoseconds  via  GPS  reception. 
However,  by  permitting  transfer  of  data  among  platforms  together  with  common  viewing  of 
multiple  GPS  satellites,  simificantlv  hieher  accuracy  may  be  achieved.  This,  in  the  words  of 
the  draft  requirements  document,  is  a  precise  restatement  of  the  principles  of  the  DGPS  RF 
algorithm.  We  have  already  demonstrated  the  capability  of  sub-nanosecond  calibration  via  the 
algorithm.  The  application  of  this  capability  to  CTR  would  be  straightforward  and  effective 
using  Link- 16  as  the  data  transfer  medium  as  explained  within  this  document.  The  potential  time 
transfer  applications  are  not  limited  to  mobile  seaborne  members.  A  reduced  DGPS  RF  state 
estimator  retaining  only  clock  bias  and  frequency  between  a  given  transmitter  and  receiver 
located  at  surveyed  positions  could  easily  bring  this  time  transfer  capability  to  land-based  remote 
stations 
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Figure  7-1:  Corporative  Link-16  Emitter  Location  Tactics  Aided  By  Precise  Community  Nav  and  Time 
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MASTER  TIME  REFERENCE 


Figure  7-2:  DGPS  RF  Algorithm  used  in  Support  of  AT3  Geolocation  Processing 


Application  of  DGPS  to  LI  6  Navigation 


Page  178 


8.  References 


Differential  Operation  of  NAVSTAR  GPS.  R.  Kalafus,  J.V.  Icons,  N.Knable.  ION  Navigation 
Journal.  March  1983.  (Reprinted  in  ION  GPS  Reprints,  Vol.  n,  June  1984). 

A  Kalman  Filter  Approach  to  Prediction  GPS  Geodesy.  R.  Brown,  P.  Y.C  Hwang.  ION 
Navigation  Journal,  December  1983.  (Reprinted  in  ION  GPS  Reprints,  Vol  n,  June  1984). 

Global  Position  Systems,  Inertial  Navigation,  and  Integration.  M.S.  Grewal.  L.  Weill,  A. 
Andrews.  Wiley  &  Sons,  2001 

Canadian  Marconi  Northstar  User’s  Manual.  Canadian  Marconi  Company,  Montreal,  Canada. 
April  2000. 

Applied  Optimal  Estimation.  Edited  by  A.  Gelb.  MIT  Press,  1974 


Appendix  A: 

Software  Requirements  Specifications 


Software  Requirements 

Specification 


Application  of  Differential  GPS  Processing  to 
Precision  Link-16  Navigation  and  Time 
Synchronization 


Version  1.0 


Prepared  by 
BAE  SYSTEMS 


March  27,  2003 


Revision  History 


Name 


Date 


Reason  For  Changes 


Version 


Appendix  A  -  SRS 


Page  A1 


Table  of  Contents 


1. 


2. 


3. 


4. 


Scope.............................................................*.——————- 

1.1  Identification . 

1 .2  System  overview . 

1 . 3  Document  Overview . 

Overall  Description.................................................... . 

2.1  Functional  Operation . 

2.2  CSCI  Versions  and  Operating  Environment . 

2.2. 1  Version  1 .0  -  PC  Simulation  Environment . 

2.2.2  Version  2.0  Laboratory  Test  Environment . 

2.2.3  Version  3.0  Baseline  Flight  Configuration . 

2.2.4  Version  4.0  Enhanced  Operational  Capability 

2.2.5  Document  Data  Nomenclature . 

Requirements.... - ...... — ......... — ......... - ....... - ....... 

3.1  RF  External  Interface  Requirements . 

3.1.1  RF  Architecture . 

3. 1 . 1 . 1  RF_EXEC_CTRL . 

3.1. 1.2  RF_SOURCE_DATA_PROC . 

3. 1 . 1 .2. 1  RF_SOURCE_DATA_EXEC . 

3.1.1.2.2  COMPARE_SAT_INDICES . 

3.1.1 .2.3  COMPUTE.  S  AT_CIRC_ECEF . 

3.1.1.2.4  COMPUTE_SAT_ELLIP_ECEF . 

3. 1.1. 2.5  XFORM_NAV_COORD . 

3.1.1 .2.6  COMPUTE_LAB_S  AT.VIS . 

3.1.1 .2.7  PROCESS_PR_DATA . 

3. 1.1. 2.8  GENERATE_KALMAN_OBS_SET . 

3. 1 . 1 .3  RF_KALMAN_PROC . 

3. 1.1. 4  OCP_INT_PROC . 

3. 1 . 1 .4. 1  PROCESS_MASTER_  MSG . 

3.1.1 .4.2  PROCESS_RAW_GPS_DATA . 

3. 1.1. 4.3  CONVERT_NAV_DATA . 

3.1.1.5  HOST_INT_PROC . 

3.1. 1.6  BUILD_MASTER_MSG . 

3. 1 . 1 .7  BUILD_RF_RESULTS_DATA . 

GLOSSARY _ 


..A4 

..A4 

..A4 

..A4 

..A5 

..A5 

..A5 

..A5 

..A6 

..A7 

..A8 

..A8 

..A9 

..A9 

A12 

A14 

A27 

A29 

A34 

A36 

A37 

A41 

A43 

A46 

A48 

A50 

A56 

A62 

A63 

A64 

A65 

A67 

A68 

.A69 


Appendix  A  -  SRS 


Page  A2 


Table  of  Figures 

Figure  2.2-1;  DGRF  V  1.0  Operation  Configuration . A6 

Figure  2.2-2:  DGRF  Version  2.0  Operational  Environment . A6 

Figure  2.2-3:  DGRF  V  3.0  Flight  Operation  Environment . A7 

Figure  3.1-1:  Top  level  system  architecture . A9 

Figure  3.1-2:  Level  1  operational  functions . A12 

Figure  3.1-3:  RF_EXEC_CTRL  Level  1  Breakdown . A14 

Figure  3.1-4:  Refinement  Filter  State  Transitions . A18 

Figure  3.1-5:  STATE  0  PROCESSING  -  Startup  state  /  RF  reset . A19 

Figure  3.1-6;  STATE  0  PROCESSING  (cont.) . A20 

Figure  3.1-7:  STATE  1  PROCESSING  -  Master  Designation  /  initialization . A21 

Figure  3.1-8:  STATE  2  PROCESSING  -  Slave  Designation  /  initialization . A22 


Figure  3.1-10:  STATE  4  PROCESSING  -  Slave  Designation  /  GPS  Pseudorange  [steady  state] 


Figure  3.1-12:  STATE  6  PROCESSING  -  Slave  Designation  /  backup  mode  [steady  state]...  A26 

Figure  3.1-13:  RF_SOURCE_DATA_PROC  Level  1  Breakdown . A27 

Figure  3.1-14:  RF_SOURCE_DATA_PROC  Level  2  breakdown . A28 

Figure  3.1-15:  RF_SOURCE_DATA_EXEC  Logical  data  flow  diagram . A32 

Figure  3.1-16:  RF_SOURCE_DATA_EXEC  Logical  data  flow  diagram  (cont.) . A33 

Figure  3.1-17:  COMPARE_SAT_INDICES  Graphical  representation  of  comparison  algorithm 


Figure  3.1-18:  XFORM_NAV_COORD  Logical  data  flow  diagram . A42 

Figure  3.1-19:  COMPlJTE_SAT_LAB_VIS  Logical  data  flow  diagram . A44 

Figure  3.1-20:  COMPUTE_SAT_LAB_VIS  Logical  data  flow  diagram  (cont.) . A45 

Figure  3.1-21:  PROCESS_PR_DATA  Logical  data  flow  diagram . A47 

Figure  3.1-22:  GENERATE_KALMAN_OBS_SET  Logical  data  flow  diagram . A49 

Figure  3.1-23:  RF_KALMAN_PROC  Level  1  Breakdown . A50 

Figure  3.1-24:  RF_KALMAN_PROC  Logical  data  flow  diagram . A53 

Figure  3.1-25:  RF_KALMAN_PROC  Logical  data  flow  diagram  (cont.) . A54 

Figure  3.1-26:  RF_KALMAN_PROC  Logical  data  flow  diagram  (cont.) . A55 

Figure  3.1-27:  OCP_INT_PROC  Level  1  Breakdown . A56 

Figure  3.1-28:  OCP_INT_PROC  Logical  data  flow  diagram . A60 

Figure  3.1-29:  OCP_INT_PROC  Logical  data  flow  diagram  (cont.) . A61 

Figure  3.1-30:  HOST_INT_PRC)C  Level  1  Breakdown . A65 

Figure  3.1-31:  HOST_INT_PROC  Level  2  Breakdown . A66 

Figure  3.1-32:  BUILD_MASTER_MSG  Level  1  Breakdown . A67 

Figure  3.1-33:  BUILD_RF_RESULTS_DATA  Level  1  Breakdown . A68 


Appendix  A  -  SRS 


Page  A3 


Table  of  Tables 

Table  3,1-1:  REFINEMENT_PROC  External  Interfaces  -  Inputs . AlO 

Table  3.1-2:  REFINEMENT_PRC)C  External  Interfaces  -  Outputs . All 

Table  3.1-3:  REFINEMENT_PROC  CSC  Descriptions . A13 

Table  3.1-4:  RF_SOURCE_DATA_PROC  SLCSC  Descriptions . A29 

Table  3.1-5:  RF_SOURCE_DATA_EXEC  Inputs . A30 

Table  3.1-6:  RF_SOURCE_DATA_EXEC  Outputs . A31 

Table  3.1-7:  RF_KALMAN_PROC  Inputs . A51 

Table  3.1-8:  RF_KALMAN_PROC  Outputs . A51 

Table  3.1-9:  HOST_INT_PROC  Input  Variables . A66 

Table  3.1-10:  HOST_INT_PROC  Output  Variables . A66 

Table  3.1-11:  HOST_INT_PROC  SLCSC  Descriptions . A66 


Appendix  A  -  SRS 


Page  A4 


1.  Scope 

1.1  IdentiHcation 

This  Software  Design  Document  (SDD)  establishes  the  architecture  and  detailed  algorithms 
description  for  the  Computer  Software  Configuration  Item  (CSCI)  identified  as  the  Differential 
GPS  Refinement  Filter  (DGRF). 

1.2  System  overview 

MIDS  is  an  advanced  information  distribution  system  that  integrates  communication,  navigation, 
and  identification  capabilities  for  application  to  airborne,  land-based,  and  maritime  tactical 
operations.  The  DGRF  represents  a  developmental  enhancement  to  the  organic  navigation 
capabilities  of  the  MIDS  terminal.  By  the  processing  of  differential  GPS  pseudorange 
measurements  received  at  a  designated  platform  (master)  and  any  other  platform,  the  DGRF 
permits  the  computation  of  relative  position  error  components  {Ax,  Ay,  Ai),  as  well  as  relative 
measures  of  Clock  Bias  (BC)  and  Frequency  Drift  (fC)  between  master  and  slave  platforms 


13  Document  Overview 

The  purpose  of  this  SDD  is  to  specify  in  detail  the  architecture  of  the  DGRF  algorithm,  and  to 
provide  a  sample  tool  (FORTRAN)  implementation  of  this  algorithm.  As  is  specified  in  more 
detail  in  Paragraph  2.0,  there  will  be  four  variants  of  the  DGRF,  which  differ  in  both  functional 
capability  and  operating  environment.  This  document  supports  the  design  and  algorithm 
requirements  of  all  four  DGPS  variants. 
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2.  Overall  Description 

2.1  Functional  Operation 

The  DGRF  relies  on  the  existing  organic  navigation  capability  of  a  L16-equipped  platform  as  a 
foundation,  a  reference  for  navigation  and  synchronization  enhancements.  The  master  platform 
provides  a  report  to  all  other  platforms,  designated  as  Master  Message.  This  message  contains 
data  relating  to  the  position  and  velocity  of  the  master  at  a  designated  time,  plus  all  received  GPS 
pseudorange  data  at  another  designated  time.  When  received  by  another  platform,  this  master 
data  will  be  combined  with  similar  navigation  and  GPS  data  received  at  own  position  within  an 
Extended  Kalman  Filter  (EKF).  The  result  of  these  calculations  is  an  optimal  estimate  of  three 
positions  and  two  time  differences  as  corrections  to  the  reference  navigation  solution. 
Performance  goals  are  one  meter  or  less  relative  positioning  and  one  nanosecond  relative  time 
between  all  platforms. 


2.2  CSCI  Versions  and  Operating  Environment 

The  DGRF  shall  be  produced  in  four  versions,  as  described  below,  which  differ  slightly  in 
operative  capability  and  operating  environment. 

•  Version  1.0-  Simulator  Version 

•  Version  2.0  -  Laboratory  Version 

•  Version  3.0  -  Basic  Operator  Version 

•  Version  4.0  -  Extended  Operator  Version  (with  backup  mode) 


2.2.1  Version  1.0  -  PC  Simulation  Environment 

Version  1.0  represents  the  FORTRAN  simulation  version  of  the  DGRF,  implementing  the  basic 
GPS-driven  capability  of  the  fundamental  estimation  algorithm.  The  true  and  estimated 
navigational  solutions  of  a  mobile  community  are  produced  by  BAE  SYSTEMS  Link  16 
Navigation  Simulator  (LNS).  A  simplified  circular  constellation  model  of  GPS  satellite  motion 
has  been  developed  and  appended.  The  LNS,  GPS  Model,  and  Vl.O  DGRF  algorithm  are  listed 
within  BAE’s  NETSIM  PC  Operating  environment.  This  configuration  will  be  utilized  for 
project  Phase  1  and  demonstration  of  DGRF  capabilities  (Figure  2.2-1). 
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NETSIM  Operating  Environment 


Figure  2.2-1:  DGRF  V  1.0  Operation  Configuration 


2.2.2  Version  2.0  Laboratory  Test  Environment 

Version  2.0  of  the  DGRF  represents  a  free-integration  of  the  DGRF  algorithm  within  the  L-16 
terminal  Operational  Computer  Program  (OCP).  It  is  designed  for  operation  on  BAE  SYSTEMS 
Terminal  ATP  Test  Set  (TATS),  which  provides  a  real-time  testing  environment  for  L-16 
terminal  assets.  V  2.0  shall  use  a  full  elliptical  GPS  model,  driving  the  1553  host  inputs  to  the 
LI  6  terminal  with  GPS  pseudorange  measurements  calculated  from  that  model  (Figure  2.2-2). 
This  version  of  the  DGRF  is  completely  equivalent  to  the  flight-operation  Version  3.0,  with  the 
exception  that  the  GPS  unit  inputs  are  simulated  with  the  TATS  unit,  and  will  be  representative 
of  the  Canadian-Marconi  North  Star  GPS  Receiver.  Version  2.0  will  be  utilized  for  project 
Phase  2  demonstration  in  March  2004. 


LINK  16  TERMINAL  UNDER  TEST 


•  REAL  DISPLAY  OF 
NAV  &  RF  RESULTS 


•  REFINEMENT  FILTER 
LINK  16  MESSAGES  - 
PSEUDORANGE/ 
EPHEMERIS  DATA 


Figure  2.2-2:  DGRF  Version  2.0  Operational  Environment 
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2.2.3  Version  3.0  Baseline  Flight  Configuration 

Version  3.0  of  the  DGRF  shall  differ  only  slightly  from  Version  2.0,  primarily  in  that  it  will  be 
tailored  to  accept  GPS  pseudorange  data  from  an  actual  GPS  unit,  type  TBD.  It  is  thus  suitable 
for  adaptation  to  flight  testing  utilizing  arbitrary  GPS  reference  units  (Figure  2.2-3). 


Figure  2.2-3:  DGRF  V  3.0  Flight  Operation  Environment 
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2.2.4  Version  4.0  Enhanced  Operational  Capability 

Version  4.0  represents  a  flight  qualified  GPRF  design  incorporating  two  potential  enhancements 
to  baseline  version: 

(a)  Incorporation  of  a  Backup  Mode  to  guarantee  graceful  degradation  of  the  precision 
navigation  solution  upon  jamming  and/or  failure  of  GPS  aiding. 

(b)  Integration  of  the  DGRF  with  the  Atmospheric  Filter  by  providing  precision 
community  navigation  data  to  the  AF  algorithm. 

Version  4.0  should  be  considered  a  “place-holder”  for  desirable  additional  capabilities  for 
precision  navigation 

2.2.5  Document  Data  Nomenclature 

Because  for  the  differing  data  requirements  of  the  four  software  versions,  certain  operation  of 
data  paths  will  be  represented  as  a  function  of  the  CSCI  Version  indicator.  These  paths  are 
labeled  as  to  version  usage  via  a  subset  of  the  integers  (1, 2,  3, 4),  where  each  number  designates 
the  version(s)  that  data  element  will  be  required. 
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3.  Requirements 

3.1  RF  External  Interface  Requirements 

This  section  specifies  external  software  interfaces  for  the  Refinement  Filter.  The  Refinement 
Filter  will  interface  with  the  Host  and  the  Link-16  Operational  Computer  Program. 


MMS  (2,  3,  4) 
MASTER_MSG  (2,  3,4) 

MS_IND(2.  3.4) 

EST_SNAV  (2, 3, 4) 

SNAV_VAL_IND  (2.  3,  4) 

MS_IND  (2,  3,  4) 
TRUE_SNAV(L2) 
TRUE_MNAV  (L  2) 
TRUE_CLOCK_BIAS  (L  2) 

TRUE_FREQ_DRIFT  (1,  2) 
PPLLDATA  (4) 
RTT_DATA  (4) 
CSCLVERSION  (I,  2,  3, 4) 


MASTER_MSG  (2,  3,  4) 

RF_RESULTS_DATA  (4) 


LINK-16 

OCP 


Pilot  GPS 


REFINEMENT 

PROCESSING 


0.0 


RF_OPR_SW  (2,  3, 4) 


SELF_GPS_DATA  (2,  3,  4) 


RF_ENABLE  (2,  3, 4) 


GPS_VAL_IND  (2,  3, 4) 


EPHEM_DATA  (2,  3,4) 


RF_HEALTH_STATUS_MSG  , 


(1,2,  3,4) 


HOST 


Figure  3.1-1:  Top  level  system  architecture 
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Inputs 

Version 

Definition 

Description 

MMS 

2,3,4 

Master  Message  Signal  - 
indicates  master  message  is 
present  and  valid 

MASTER_MSG 

2,3,4 

MNAVTOV,  MLAT,  MLON, 
MALT,  MEVEL,  MNVEL, 
MALTR,  GPS_HEALTH_IND, 
MGPSTOV,  UMSAT,  UMPRR 

Master's  Navigation  solution, 
along  with  master  GPS  data 

SNAV_VAL_IND 

2,3,4 

Self  Navigation  Validity- 
Indicator 

EST_SNAV 

1,2, 3, 4 

SLAT,  SLON,  SALT, 

SEVEL,  SNVEL,  SALTR, 
SNAVTOV 

Navigation  solution  from  L16 
OCP 

MS_IND 

2,3,4 

Master/Slave  indicator 

TRUE_SNAV 

1,2 

TSLAT,  TSLON,  TSALT, 
TLATR,  TLONR,  TSALTR, 

TSNAVTOV 

TRUE  SELF  navigation  solution 

TRUE_MNAV 

1,2 

TMLAT,  TMLON,  TMALT, 
TMLATR,  TMLONR, 

TMALTR,  TMNAVTOV 

TRUE  MASTER  navigation 
solution 

TRUE_CLOCK_BIAS 

1,2 

BCTRUE 

TRUE  clock  bias 

TRUE_FREQ__DRI  FT 

1,2 

FCTRUE 

TRUE  frequency  drift 

PPLI_DATA 

4 

Requested  PPLI 

RTT_DATA 

4 

Requested  RTT 

CSCI_VERSION 

CSCI_VERS_ID 

Denotes  operational  version 

RF__OPR_SW 

Reset/Initiate  signal  from 

Host  pilot 

SELF_GPS_DATA 

USSAT,  USPRR,  SGPSTOV, 
GPS_HEALTH_IND 

Received  GPS  data  from  HOST 

RF_ENABLE 

ON/OFF  switch 

GPS_VAL_IND 

2,3,4 

GPS  validity  Indicator 

EPHEM_DATA 

2,3,4 

EPHEM(30,23) 

Ephemeris  satellite  data 
received  from  the  host  for 
pseudorange  calculations 

Table  3.1-1:  REFINEMENT_PROC  External  Interfaces  -  Inputs 
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Outputs 


Version 


Definition 


Description 


MASTER  MSG 


2,3,4 


MNAVTOV,MLAT,  MLON, 
MALT,  MEVEL,  MNVEL, 
MALTR,  GPS__HEALTH_IND, 
MGPSTOV,  UMSAT,  UMPRR 


Master's  Navigation 
solution,  along  with  master 
GPS  data 


RF  RESULTS  DATA 


XA,  PA 


Refinement  Filter 
corrections  and  covariance 
message  sent  to  L16  OCP  for 
AF 


RF_HEALTH_ 
STATUS  MSG 


1,2, 3, 4 


RF_STATE , 

RF_STATUS_IND,  XA,  PA, 
SCOUNT,  SATVIS, 

SNAVTOV 


Indicates  health  of  the 
refinement  filter  to  the 
host  to  determine  whether 
the  filter  should  be  reset, 
switch  to  backup  mode,  or 
system  normal . 


Table  3.1-2:  REFINEMENT^PROC  External  Interfaces  -  Outputs 
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3.1.1  RF  Architecture 

The  Refinement  Processing  is  organized  into  six  operational  CSC’s  depicted  below. 


CSCI_VERS_ID  (1.2,  3,  4) 


RF_OPR_SW  (1,  2,  3,  4) 


Figure  3.1-2:  Level  1  operational  functions 
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CSC 

Description 

RF_EXEC_CTRL 

Controls  the  data  flow  within  Refinement  Processing 
depending  on  inputs  to  the  system. 

RF_SOURCE_DATA_PROC 

Prepares  and  synchronizes  all  data  for  Kalman  filtering. 

RF_KALMAN_PROC 

Applies  Kalman  filtering  to  the  data  passed  from  the 
RF_SOURCE_DATA_PROCESSING  unit. 

HOST_INT_PROC 

Interfaces  with  host  and  processes  data  that  enters  this 
system  from  the  host,  mainly  control  signals  and  GPS  data. 

OCP_INT_PROC 

LI 6  OCP  interface  from  which  all  OCP  data  enters  the 
system,  mainly  navigation  solution  including  position, 
velocity,  and  time. 

BUILD_MASTER_MSG 

Called  if  the  platform  is  designated  the  master  of  the 
network  from  the  host.  The  master  message  is  sent  at  a  2 

Hz  rate  to  all  the  slaves  in  the  network. 

BUILD_RF_RESULTS_DATA 

Called  at  the  end  of  each  time  step  if  the  platform  is 
designated  a  slave  at  the  host.  This  block  composes  a 

Packed  4  message  to  be  used  in  the  Atmospheric  Filter 
contained  within  the  Link- 16  Operational  Computer 
Program. 

Table  3.1-3;  REFINEMENT_PROC  CSC  Descriptions 
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3.1.1.1  RF_EXEC_CTRL 

The  Refinement  Filter  Executive  Control  (RF_EXEC_CTRL)  serves  as  a  conductor  for  the  entire 
Refinement  Process.  It  conducts  the  flow  of  data  between  the  interface  processing  CSCs  and  the 
Hata  processing  CSCs.  The  refinement  filter  can  be  represented  by  a  finite  state  machine  with  7 
states.  The  RF_EXEC_CTRL  then  determines  the  state  of  the  filter  depending  on  the  health  of 
incoming  data,  validity  checks,  and  control  inputs. 


CSCI_VERS_ID  (1,  2,  3, 4) 


Figure  3.1-3;  RF_EXEC_CTRL  Level  1  Breakdown 
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CSC  Inputs 

Version 

Definition 

Description 

CSCI_VERS_ID 

1,2, 3, 4 

Denotes  operational  version 

GPS_HEALTH_IND 

2,3,4 

Indicates  the  health  status 
of  GPS  signal.  When  this 
signal  is  too  weak,  backup 
mode  takes  over. 

MMS 

2,3,4 

Master  Message  Indicator: 
Check  if  the  master  message 
is  ready  for  transmission 

MS_IND 

2,3,4 

Master/Slave  Indicator: 

Checks  for  pilot  designation 
for  platform  either  master 
or  slave  aircraft. 

RF_ENABLE 

2,3,4 

On/Off  Switch 

RF_KALMAN_RESULTS_ 

PKG 

1,2, 3, 4 

Time  (TC) , 
RF_STATE,  RSI,  | 
XA,  PA 

Refinement  Filter  results 
and  covariance,  XA  and  COV 

RF_OPR_SW 

1,2, 3, 4 

Refinement  filter  operation 
switch:  ON/OFF  switch  for 
system  initialization/reset 

GPS_VAL__IND 

2,3,4 

Master  Navigation  Validity 
Indicator 

SNAV_VAL_IND 

2,3,4 

Self  Navigation  Validity 
Indicator 

CSC  Outputs 

Version 

Description 

CSCI_VERS_ID 

1,2, 3, 4 

Denotes  operational  version 

RF_HEALTH_STAT_MSG 

1,2, 3, 4 

RF_STATE, 

RF_STATUS_IND, 

XA,  PA,SCOUNT, 
SATVIS,SNAVTOV 

Indicates  health  of  the 
refinement  filter  to  the 
host  to  determine  whether 
the  filter  should  be  reset, 
switch  to  backup  mode,  or 
system  normal. 

RF__STATE 

3,4 

Indicates  the  state  value  of 
the  refinement  filter  (See 
below  for  definitions  of 
states) .  [OUTPUTS  TO 

OCP_INT_PROC] 

RF_STATE 

1,2, 3, 4 

Indicates  the  state  value  of 
the  refinement  filter  (See 
below  for  definitions  of 
states) .  [OUTPUTS  TO 

RF__Kalman_Proc  Module] 

Appendix  A  -  SRS 


Page  A16 


RF_STATUS_INDICATOR  (RSI) 


RSI  1 

Status 

Conditions 

RF  Inoperative 

Off  Selected 

1 

RF  Inoperative 

SNAV_VAL_IND  =  invalid 

2 

RF  Inoperative 

MNAV_VAL_IND  =  invalid 

3 

RF  Inoperative 

GPS  failure 

4 

RF  Operative 

Normal  Mode  /  Non  Steady  State 

5 

RF  Operative 

Normal  Mode  /  Steady  State 

6 

RF  Operative 

Backup  /  Non  Steady  State 

7 

RF  Operative 

Backup  /  Steady  State 

8 

RF  Master  Mode 

9 

RF  Observation  Failure  Reset 

Command 

RF_STATE 

The  Refinement  Filter  can  be  represented  as  a  finite  state  machine  with  seven  states. 

State  0  -  Initial  startup  state,  RF  reset 

•  If  the  filter  should  fail  any  validity  check,  become  instable,  or  obtain  deficient 
observations,  it  returns  to  this  state 

State  1  -  Master  designation 

•  Requires  no  Kalman  Processing 

State  2  -  Slave  designation  /  not  yet  initialized 

•  Initializes  filter  variables 

■  PA,  PX,  QA,  RA 

•  RTT_REQUEST  =  OFF 

State  3  -  Slave  Designation  /  GPS  Pseudorange  -  steady  state  not  achieved 

•  Normal  mode 

•  Filter  working,  not  yet  steady  state 

State  4  -  Slave  Designation  /  GPS  Pseudorange  -  steady  state  achieved 

•  state  at  which  RF  will  most  likely  exist 


State  5  -  Slave  Designation  /  RTT,  PPLI  -  backup  mode  initialization  (not  steady  state) 
•  GPS  problem 

•  Insufficient  signal  strength 

•  Number  of  satellites  in  view  fall  under  minimum  requirement 
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•  RTT_REQUEST  =  ON 

•  Using  PPLI/RTT  in  Kalman  Processing 

•  Reconfigure  RF:  5  8  states 

•  Steady  state  not  yet  achieved 

State  6  -  Slave  Designation  /  backup  mode  -  steady  state  achieved 

•  Backup  until  GPS  becomes  available 


The  state  of  the  refinement  filter  determines  the  output  of  the  RF_EXEC_CTRL 

The  following  diagrams  depict  the  transition  conditions  between  states  of  the  refinement  filter 
and  the  logical  dataflow  and  processes  called  within  each  state. 
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Figure  3.1-5:  STATE  0  PROCESSING  -  Startup  state  /  RF  reset 
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Figure  3.1-6:  STATE  0  PROCESSING  (cont.) 
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Rlter/variable 

Initialization 


CALL 

HOST  INT.PROC 


RF_OPR_SW 


CALL 

OCP_INT_PROC 


SNAV_VAL_ 
IND  =  valid? 


GPS_VAL_ 
IND  =  valid? 


CALL 

BUILD_MASTER 

MSG 


GENERATE 

RF_HEALTH_ 

STATUS_MSG 


RSI  =  0 

RF_STATE  =  0 


SET: 

RSI=1 

RF_STATE  =  0 


SET: 
RSI  =  3 


Figure  3.1-7:  STATE  1  PROCESSING  -  Master  Designation  /  imtiahzation 
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Filter/variable 

Initialization 


CALL 

HOST_INT_PROC 


RF_OPR_SW 


SET: 

RSI  =  0 

RF_STATE  =  0 


CALL 

OCP_INT_PROC 


SNAV_VAL_ 
IND  =  valid? 


SET: 

RS1=1 

RF_STATE  =  0 


GPS_VAL_ 
IND  =  valid? 


SET: 

RSI  =  3 

RF  STATE  =  0 


MNAV_VAL_ 
IND  =  valid? 


SET: 

RSI  =  2 

RF  STATE  =  0 


SET: 

RSI  =  6 

RF_STATE  =  5 


INSUinCIENT 


GPS 

Strength/#? 


GENERATE 

RF__HEALTH_ 

STATUS.MSG 


Figure  3.1-8:  STATE  2  PROCESSING  -  Slave  Designation  /  initialization 
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CALL 

HOST_INT_PROC 


RF  OPR  SW 


SET: 

RSI  =  0 

RF  STATE  =  0 


CALL 

OCP_INT_PROC 


SNAV_VAL_ 
IND  =  valid? 


SET: 

RSI=1 

RF_STATE  =  0 


GPS_VAL_ 
EMD  =  valid? 


SET: 

RSI  =  3 

rf_state  =  o 


MNAV_VAL_ 
IND  =  valid? 


SET: 

RSI  =  2 

RF_STATE  =  0 


SET: 

RSI  =  6 

RF^STATE  =  5 


^INSUFnCIENT 


GPS 

Strength/#? 


CALL 

RF  SOURCE_DATA_P 
ROC 

CALL 

RF_KALMAN_PROC 

SET: 

RSI  =  5 

RF_ST  ATE  =  4 


Steady  State? 


METRIC  <  SSLM 


GENERATE 
RF_HEALTH_ 
STATUS  MSCf 


Figure  3.1-9:  STATE  3  PROCESSING  -  Slave  Designation  /  GPS  Pseudorange  [not  ss] 
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CALL 

HOST_INT_PROC 


RF_OPR_SW 


SET: 

RSI  =  0 

RF_STATE  =  0 


CALL 

OCP_INT_PROC 


SNAV_VAL_ 
IND  =  valid? 


SET: 

RSI=1 

RF_STATE  =  0 


GPS_VAL_ 
JNT)  = 


SET: 

RSI  =  3 

RF  STATE  =  0 


MNAV„VAL_ 
IND  =  valid? 


SET: 

RSI  =  2 

RF_STATE  =  0 


SET: 

RSI  =  6 

RF_STATE  =  5 


^INSUFnCIENT 


GPS 

Strength/#? 


CALL 

RF_SOURCE_DATA_P 

ROC 


CALL 

RF_KALMAN_PROC 


GENERATE 

RF_HEALTH_ 

STATUS.MSG 


Figure  3.1-10:  STATE  4  PROCESSING  -  Slave  Designation  /  GPS  Pseudorange  [steady  state] 
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CALL 

HOST_INT_PROC 


RF_OPR_SW 


SET: 

RSI  =  0 

RF_ST  ATE  =  0 


RTT_REQUEST_ 

IND 


CALL 

OCP_INT_PROC 


SNAV_VAL_ 
IND  =  valid? 


SET: 

RSI=1 

RF„STATE  =  0 


MNAV_VAL_ 
IND  =  valid? 


SET: 

RSI  =  2 

RF_STATE  =  0 


SET: 

RSI  =  4 

RF  STATE  =  2 


SUFFICIENT 


GPS 

Strength/#? 


INSUFnCIENT 


CALL 

RF  SOURCE  DATA  P 
ROC 

;  _ 

CALL 

RF_KALMAN_PROC 

SET: 

RSI  =  7 

RF_STATE  =  6 


Steady  State? 


METRIC  <  SSLIM 


GENERATE 

RF.HEALTH^ 

STATUS_MSG 


Figure  3,1-11:  STATE  5  PROCESSING  -  Slave  Designation  /  RTT,  PPLI  [backup  mode] 
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CALL 

HOST_INT_PROC 


RF_OPR_SW 


SET: 

RSI  =  0 

RF_STATE  =  0 


CALL 

OCP_INT_PROC 


SNAV^VAL. 
IND  =  valid? 


SET: 

RSI=1 

RF_STATE  =  0 


MNAV_VAL_ 
IND  =  valid? 


SET: 

RSI  =  2 

RF_STATE  =  0 


SET: 

RSI  =  4 

RF  STATE  =  2 


GPS 

Strength/#? 


INSUFFICIENT 


GENERATE 

RF_HEALTH_ 

STATUS_MSG 


Figure  3.1-12:  STATE  6  PROCESSING  -  Slave  Designation  /  backup  mode  [steady  state] 
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3.1.1.2  RF^SOURCE_DATA_PROC 

The  Refinement  Filter  Source  Data  Processing  unit  synchronizes  and  prepares  data  for  Kalman 
processes.  Master  GPS  and  Navigation  data  are  extracted  from  the  master  message.  This  data  is 
then  paired  with  the  platform’s  own  navigation  solution.  It  is  essential  that  all  data  is  time 
synchronized  before  the  Kalman  filter  can  be  applied. 


MNAV_DATA  (1,  2.  3,  4) 

OCP 

INT  SN AV.DATA  (1 ,  2,  3,  4) 

PROC 


CSCI_VERS_ID 
fl.  2.  3. 4^ 


RF_SOURCE_DATA 

PROC 


GPS_PR_DATA  (2,  3,  4) 


INVERS  (2,  3, 4) 


HOST 

INT 

PROC 


KALMAN_OBS_SET 
(1.2,3, 4) 


RF.KALMAN 

PROC 


Figure  3.1-13:  RF_SOURCE_DATA^PROC  Level  1  Breakdown 


- — - — — 

CSC  Outputs 

Description 

KALMANJDBS_SET 

Data  contains  from  Satellite  or  PPLI/RTT  Data 
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\ 


RF_  SOURCE_DATA_EXEC 


COMPARE_SAT_ 

INDICES 


XFORM  _NAV_COORD 


COMPUTE_SAT_ 

COMPUTE_SAT_ 

CIRC.ECEF 

ELLIP.ECEF 

PROCESS_PR_DATA 


COMPUTE_SAT_ 

COMPUTE_SAT_^ 

LAB.VIS 

FIELD.VIS 

PPLI_RTT_SCREEN 


GENERATE_KALMAN 


Ol7'T' 


Figure  3.1-14:  RF_SOURCE_DATA_PROC  Level  2  breakdown 
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k 

SLCSC _ 

RF  SOURCE  DATA  EXEC 


COMPARE  SAT  INDICES 


COMPUTE  SAT  CIRC  ECEF 


COMPUTE  SAT  ELLIP  ECEF 


COMPUTE  SAT  LAB  VIS 


COMPUTE  SAT  FIELD  VIS 


XFORM  NAV  COORD 


PPLI  RTT  SCREEN 


PROCESS  PR  DATA 


GENERATE  KALMAN  OBS  SET 


Description _ 

Coordinates  self  navigation  (HOST)  with  master 
navigation  solution  (OCP) . 

Coordinates  execution  of  subroutines  within 
RF_SODRCE_DATA  PROC _ 

Compares  measured  satellite  indices  for  master/slave. 
Selects  candidate  observation  group  for  common  elements. 

Computes  Satellite  ECEF  elements  for  common  satellites 
when  CSCI_VERS_ID  =2.0  (Laboratory  Mode) _ 

Computes  Satellite  ECEF  elements  for  common  satellites 
when  CSCI_VERS_ID  =3.0  (Field  Mode) _ 

Only  satellites  at  least  5o  above  horizon  are  candidates 
when  CSCI_VERS_ID  =  2.0  (Laboratory  Mode) _ 

Only  satellites  at  least  5o  above  horizon  are  candidates 
when  CSCI_VERS_ID  =3.0  (Field  Mode) _ 

Transforms  self -navigation  into  Local  Level  and  ECEF 
coordinates . 

Called  only  when  CSCI_VERS_ID  =  4.0  (Backup  Mode) 

Takes  PPLI/RTT  Data  when  GPS  is  not  valid. 

Converts  satellite  code  phase  data  from  master  and  self 
to  generate  arrays  of  psuedorange  data  from  all  common 
satellites  in  units  of  meter _ 

Generates  Kalman  Observation  set  from  Satellite  or 


_ I  PPLI/RTT  Data _ 

Table  3,1-4:  RF_SOURCE_DATA_PROC  SLCSC  Descriptions 


3.1.1.2.1  RF_SOURCE_DATA_EXEC 

This  SLCSC  coordinates  the  (asynchronous)  host  NAV  data  with  master  message-derived 
navigation  data.  The  RF_SOURCE_DATA_EXEC  controls  all  execution  modes  of  system 
operation  (i.e  laboratory  or  field).  This  SLCSC  also  coordinates  the  execution  of  the  various 
subordinate  routines  with  RF_Source_Data_Processing  module. 
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INPUTS 

DESCRIPTION 

MNAV  DATA 

MNAVTOV 

Time  of  Validity  of  MASTER  Navigation  solution 

MIiAT 

ESTIMATED  MASTER  Latitude  position  [rad] 

MLATR 

ESTIMATED  MASTER  Latitude  rate  [rad/s] 

MLON 

ESTIMATED  MASTER  Longitude  position  [rad] 

MLONR 

ESTIMATED  MASTER  Longitude  rate  [rad/s] 

MALT 

ESTIMATED  MASTER  Altitude  [m] 

MALTR 

ESTIMATED  MASTER  Altitude  rate  [m/s] 

TMLAT* 

TRUE  MASTER  Latitude  position  [rad] 

TMLATR* 

TRUE  MASTER  Latitude  rate  [rad/s] 

TMLON* 

TRUE  MASTER  Longitude  position  [rad] 

TMLONR* 

TRUE  MASTER  Longitude  rate  [rad/s] 

TMALT* 

TRUE  MASTER  Altitude  [m] 

TMALTR* 

TRUE  MASTER  Altitude  rate  [m/s] 

MSAT(12) ** 

MASTER  Ordered  Satellite  List 

MPRR(12) ** 

MASTER  Ordered  measured  code  phase  array 

MGPSTOV** 

MASTER  predicted  GPS  time  of  validity 

MVIS** 

Number  of  satellites  visible  to  MASTER 

BCTRUE 

TRUE  MASTER  Clock  Bias 

FCTRUE 

TRUE  MASTER  Frecfuency  Drift 

SNAV_DATA 

SNAVTOV 

Time  of  Validity  of  SELF  Navigation  solution 

SLAT 

ESTIMATED  SELF  Latitude  position  [rad] 

SLATR 

ESTIMATED  SELF  Latitude  rate  [rad/s] 

SLON 

ESTIMATED  SELF  Longitude  position  [rad] 

SLONR 

ESTIMATED  SELF  Longitude  rate  [rad/s] 

SALT 

ESTIMATED  SELF  Altitude  [m] 

SALTR 

ESTIMATED  SELF  Altitude  rate  [m/s] 

TSLAT* 

TRUE  SELF  Latitude  position  [rad] 

TSLATR* 

TRUE  SELF  Latitude  rate  [rad/ s] 

TSLON* 

TRUE  SELF  Longitude  position  [rad] 

TSLONR* 

TRUE  SELF  Longitude  rate  [rad/s] 

TSALT* 

TRUE  SELF  Altitude  [m] 

TSALTR* 

TRUE  SELF  Altitude  rate  [m/s] 

SSAT(12) ** 

SELF  Ordered  Satellite  List 

SPRR(12) ** 

SELF  Ordered  measured  code  phase  array 

SGPSTOV** 

SELF  predicted  GPS  time  of  validity 

SVIS** 

Number  of  satellites  visible  to  SELF 

BCTRUE 

TRUE  SELF  Clock  Bias 

FCTRUE 

TRUE  SELF  Frequency  Drift 

INVERSOO)  ** 

Satellite  sorting  index 

EPHEM(30,23) ** 

Satellite  Ephemeris  Data 

CSCI  VERS  IND 

NVS 

RF  STATE 

Table  3.1-5:  RF  SOURCE_DATA_EXEC  Inputs 
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OUTPUTS 

DESCRIPTION 

MNAV  DATA 

MNAVTOV 

Time  of  Validity  of  MASTER  Navigation  solution 

MLAT 

ESTIMATED  MASTER  Latitude  position  [rad] 

MLATR 

ESTIMATED  MASTER  Latitude  rate  [rad/s] 

MLON 

ESTIMATED  MASTER  Longitude  position  [rad] 

MLONR 

ESTIMATED  MASTER  Longitude  rate  [rad/s] 

MALT 

ESTIMATED  MASTER  Altitude  [m] 

MALTR 

ESTIMATED  MASTER  Altitude  rate  [m/s] 

TMLAT* 

TRUE  MASTER  Latitude  position  [rad] 

TMLATR* 

TRUE  MASTER  Latitude  rate  [rad/s] 

TMLON* 

TRUE  MASTER  Longitude  position  [rad] 

TMLONR* 

TRUE  MASTER  Longitude  rate  [rad/s] 

TMALT* 

TRUE  MASTER  Altitude  [m] 

TMALTR* 

TRUE  MASTER  Altitude  rate  [m/s] 

MSAT(12) ** 

MASTER  Ordered  Satellite  List 

MPRR(12) ** 

MASTER  Ordered  measured  code  phase  array 

MGPSTOV** 

MASTER  predicted  GPS  time  of  validity 

MVIS** 

Number  of  satellites  visible  to  MASTER 

BCTRUE 

TRUE  MASTER  Clock  Bias 

FCTRUE 

TRUE  MASTER  Frequency  Drift 

SNAV  DATA 

SNAVTOV 

Time  of  Validity  of  SELF  Navigation  solution 

SLAT 

ESTIMATED  SELF  Latitude  position  [rad] 

SLATR 

ESTIMATED  SELF  Latitude  rate  [rad/s] 

SLON 

ESTIMATED  SELF  Longitude  position  [rad] 

SLONR 

ESTIMATED  SELF  Longitude  rate  [rad/s] 

SALT 

ESTIMATED  SELF  Altitude  [m] 

SALTR 

ESTIMATED  SELF  Altitude  rate  [m/s] 

TSLAT* 

TRUE  SELF  Latitude  position  [rad] 

TSLATR* 

TRUE  SELF  Latitude  rate  [rad/s] 

TSLON* 

TRUE  SELF  Longitude  position  [rad] 

TSLONR* 

TRUE  SELF  Longitude  rate  [rad/s] 

TSALT* 

TRUE  SELF  Altitude  [m] 

TSALTR* 

TRUE  SELF  Altitude  rate  [m/s] 

SSAT(12) ** 

SELF  Ordered  Satellite  List 

SPRR(12) ** 

SELF  Ordered  measured  code  phase  array 

SGPSTOV** 

SELF  predicted  GPS  time  of  validity 

SVIS** 

Number  of  satellites  visible  to  SELF 

BCTRUE 

TRUE  SELF  Clock  Bias 

FCTRUE 

TRUE  SELF  Frequency  Drift 

INVERSOO)** 

Satellite  sorting  index 

EPHEM{30,23) ** 

Satellite  Ephemeris  Data 

CSCI  VERS  IND 

NVS 

RF  STATE 

Table  3.1-6:  RF_SOURCE_DATA_EXEC  Outputs 


*  -  Provided  only  if  CSCI_VERS_IND  =  2  (Laboratory  Mode) 
**  -  Provided  only  if  CSCI_VERS_IND  =  3  (Field  Mode) 
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FIRST  CALL  -  USE  EST  j 

j  NAV  DATA  ; 

j  _ ^  MLLPX  1 

:  MLLP=MLLPY  i 

!  MLLPZ  ^ 

r _ ^  SLLPX  j 

!  SLLP  =  SLLPY 

!  SLLPZ  ! 


'  SECOND  CALL  -  USE  j 

i  TRUE  NAV  DATA  ' 

i  TMLLPX  i 

I  TMLLP  =  TMLLPY  | 
^  TMLLPZ  j 

r - 

_ ^  TSLLPX  j 

I  TSLLP  =  TSLLPY 
!  TSLLPZ  ■ 


Figure  3.1-15:  RF_SOURCE_DATA_EXEC  Logical  data  flow  diagram 
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3.1.1.2.2  COMPARE_SAT_INDICES 

COMPARE_SAT_INDICES  compares  ordered  satellite  indices  for  master/slave  and  selects  the 
common  satellites.  These  satellites  are  aligned  in  a  single  array  containing  data  required  for 
pseudorange  comparison. 


INPUTS 

DESCRIPTION 

MSAT(12) 

Ordered  array  of  MASTER  visible  satellites 

SSAT(12) 

Ordered  array  of  SELF  visible  satellites 

MPRR{12) 

Ordered  array  of  MASTER  code  phase 

SPRR{12) 

Ordered  array  of  SELF  code  phase 

OUTPUTS 

DESCRIPTION 

NVS 

Number  visible  satellites  -  common  to  MASTER  and  SELF 

SAT(NVS) 

Ordered  array  of  common  visible  satellites 

PRRl (NVS) 

MASTER  array  of  code  phase  for  common  satellites 

PRR2 (NVS) 

SELF  array  of  code  phase  for  common  satellites 

MVIS 

Number  of  satellites  visible  to  MASTER 

SVIS 

Number  of  satellites  visible  to  SELF 

Figure  3.1-17:  COMPARE_SAT_INDICES  Graphical  representation  of  comparison  algorithm 
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Comparison  Algorithm: 


FOR  i  =  1,  MVIS 
FOR  j  =  1,  SVIS 

IF  MSAT{i)  =  SSAT(j) 

THEN  Store  satellite  ID  in  array  SAT{NVS)  and  pseudoranges  in 
corresponding  PRRl (NVS)  and  PRR2 (NVS)  arrays 
IF  SSAT(j)  >  MSAT(i)  end  inner  loop 


SAr(l) 

SATd) 


= Ordered  list  of  matched  satellite  ID'S 


SAT(NVS) 


Where : 

NVS  =  #  of  Matched  Satellites 

SAT(j)  -  Satellite  indices  satisfying  match 


Code  phase  pseudorange  data  for  satellites  contained  in  ordered  array  SAT(NVS)  is  transferred 
to  corresponding  processed  raw  pseudorange  arrays  containing  only  data  for  matched  satellites: 
MPRR(12)  PRRl  (NVS) 

SPRR(12)  ^  PRR2(NVS) 


Algorithm  Pseudocode: 

NVS  =  0,  SAT(i)  =  0,i=l,  12 

DO  X  I  =  1,  MVIS 
DO  Y  J  =  1,  SVIS 

CASE:  MSAT(I)  =  SSAT ( J) 
NVS  =  NVS  +  1 
SAT (NS)  =  MSAT(I) 
PRRl (NS)  =  MPRR(I) 
PRR2{NS)  =  SPRR(J) 
EXIT  y  LOOP 

CASE:  MSAT(I)  <  SSAT { J) 
EXIT  y  LOOP 

CASE:  MSATd)  >  SSAT(J) 
CONTINUE  Y  LOOP 
Y  CONTINUE 
X  CONTINUE 
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3.1.1.2.3  COMPUTE.  SAT_CIRC_ECEF 

This  SLCSC  performs  the  conversion  of  the  circular  satellite  constellation  coordinates  into  Earth 
Centered  Earth  Fixed  coordinates  for  the  laboratory  model. 

Conditions: 

CSCLVERS.IND  =  2.0  (Laboratory  Mode) 

GPS_VAL_IND  =  valid 


INPUTS 

DESCRIPTION 

SGPSTOV 

GPS  system  time 

NVS 

Number  visible  satellites  -  common  to  MASTER  and  SELF 

SAT  (NVS) 

Ordered  array  of  common  visible  satellites 

OUTPUTS 

DESCRIPTION 

ECEFXS (K) 

ECEF  x-coordinate  for  satellite  K 

ECEFYS(K) 

ECEF  y-coordinate  for  satellite  K 

ECEFZS(K) 

ECEF  Z“Coordinate  for  satellite  K 

Stored  Constants: 


OMEGAO(K),  K  =  1,  30 

ETAO (I) ,  K  =  1,  30 

OMEGAE  =  7.292115467  E-5  [RAD/S] 

OMEGAS  =  1.45858522  E-4  [RAD/S] 

RK  =  87051108  [meters] 

IOTA  =  55.0/2*pi  [RAD] 


Lat  coordinates  of  satellites 
Lon  coordinates  of  satellites 
Earth's  rotational  rate 
Satellite  orbital  rate 
Radius  of  satellite  orbit 
Satellite  Inclination 


Circular  constellation  propagation  algorithm: 

FOR  K  =  1,  NVS 

OMEGAK  =  OMEGAO  (SAT  (K) )  -  TC  *  OMEGE 
ETAK  =  ETA  (SAT  (K) )  +  TC  *  OMEGS 

ECEF  (1,  1)  =  XKP*DCOS  (OMEGAK)  -  YKP*DSIN  (OMEGAK) *DCOS  (IOTA) 

ECEF  (2,  1)  =  XKP*DSIN  (OMEGAK)  +  yKP*DCOS  (OMEGAK) *DCOS  (IOTA) 

ECEF  (3,  1)  =  YKP*DSIN  (IOTA) 
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3.1.1.2.4  COMPUTE_SAT_ELLIP_ECEF. 

This  SLCSC  performs  the  conversion  of  Elliptical  satellite  constellation  coordinates  into  ECEF 
coordinates  for  the  real  flight  model. 


INPOTS _ 

EPHEM(23,30) 

NVS 

SAT{NVS) 
INVERS(30) 
SGPSTOV 
PRR2 (NVS) 


DESCRIPTION _ 

Satellite  Ephemeris  Data 

Number  visible  satellites  -  common  to  MASTER  and  SELF 
Ordered  array  of  common  visible  satellites 
Satellite  sorting  index 
Predicted  GPS  time 

SELF  array  of  code  phase  for  common  satellites 


OUTPUTS 

ECEFXS (L) 
ECEFYS (L) 
ECEFZS (L) 


DESCRIPTION _ 

ECEF  x-coordinate  for  satellite  L 
ECEF  y-coordinate  for  satellite  L 
ECEF  z-coordinate  for  satellite  L 


Satellite  Ephermis  Data  for  all  satellites  (visible  or  not).  Ephermis  Data  Indexed  in  Following 


Order: 

SVNO 

=  EPHEM  (1, 1) 

WEEKNO 

=  EPHEM  (I,  2) 

TGD 

=  EPHEM  (I,  3) 

TOC 

=  EPHEM  (1, 4) 

NOTE:  I  is  EPHEM 

AF2 

=  EPHEM  (I,  5) 

array  index,  not 

AFl 

=  EPHEM  (1, 6) 

satellite  #,  We  will 

AFO 

=  EPHEM  (I,  7) 

later  use  INVERS 

CRS 

=  EPHEM  (I,  8) 

array  to  reference 

DELTAN 

=  EPHEM  (I,  9) 

desired  satellite  index. 

MO 

=  EPHEM  (1, 10) 

cue 

=  EPHEM  (1, 11) 

Dimension  of  EPHEM 

ES 

=  EPHEM  (1, 12) 

CUS 

=  EPHEM  (1, 13) 

SQRTAS 

=  EPHEM  (1, 14) 

TOE 

=  EPHEM  (I,  15) 

CIC 

=  EPHEM  (1, 16) 

OMEGAO 

=  EPHEM  (1, 17) 

CIS 

=  EPHEM  (1, 18) 

lOTAO 

=  EPHEM  (1, 19) 

CRC 

=  EPHEM  (1, 20) 

OMEGA 

=  EPHEM  (1, 21) 

OMEGADT 

=  EPHEM  (1, 22) 

lOTADT 

=  EPHEM  (1, 23) 

I  index  is  determined  by  order  that  GPS  reports  PR  data.  Host  interface  processing  will 
provide  INVERS  array  to  allow  correct  indexing 
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Conditions: 


CSCI_VERS_ID  =  3.0  (Field  Mode) 
GPS_VAL_IND  =  valid 


Stored  Constants: 


RK  =  87051108  [meters] 

C  =  2.99792498  E8 [m/s] 

CR 

OMEGAE  =  7.292118467  E-5 
OMEGAS  =  1.45858522  E-4 
MU  =  3.986008  E14 
F  =  -4.442807633  E-10 


Radius  of  satellite  orbit 
Speed  of  light  in  vacuum 
Code  phase  conversion  factor 
Earth's  rotational  rate 
Satellite  orbital  rate 

? 


Algorithm  Pseudocode: 

Compute  psuedorange 

IPGPS  =  PGPST 

FPGPS  =  PGPST  -  FLOAT (IPGPS) 
PRSEC  =  FPGPS  -  (CDPHSE/CR) 
IF  (PRSEC  <  0.0)  THEN 

PRSEC  =  1.0  +  PRSEC 


TC  =  PGPSTM  -  PR/C 

TOE  =  EPHEMdNVERSdSVNO)  ,15) 

TK  =  TC  -  TOE 

IF  (TK  >  302400.0)  THEN 
TC  =  TC  -  604800.0 
IF  (TK  <  302400.0)  THEN 
TC  =  TC  +  604800.0 


Compute  mean  motion 

DELN  =  EPHEMdNVERSdSVNO)  ,9) 
SAS  =  EPHEMdNVERS  (ISVNO)  ,  14) 
AS  =  SAS* 2 

N  =  DSQRT(MU/AS*3)  +  DELN 

Confute  mean  anomaly 

MO  =  EPHEMdNVERSdSVNO)  ,10) 

MK  =  MO  +  N*(TC  -  TOE) 

Solve  for  eccentric  emomaly 

ES  =  EPHEM ( INVERS ( ISVNO) , 12 ) 

EKNEW  =  MK 

FOR  JX: 1:100  DO 

EKOLD  =  EKNEW 

EKNEW  =  MK  +  ES*SIN (EKOLD) 


Integer  value  of  PGPST 
Fractional  GPS 

Pseudorange  in  seconds  from  code  phase 
Numerical  validity  check 


Multiply  by  C  for  true  pseudorange 
Coarse  GPS  system  time 
Ephemeris  reference  time  (from  Epoch) 
Difference  between  TC  and  TOE 


mean  motion  difference  [semicircle/s] 
Square  root  of  semi -major  axis  [m*l/2] 
Semi -major  axis 
Computed  mean  motion 


Mean  anomaly  at  reference  time  [smcir] 
Mean  anomaly 

E  +  MK  +  ES*SIN(EOLD)  [Newton-Raphson] 
Eccentricity 

Kepler's  equation  for  Eccen.  anomaly 


END 
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E  =  EKNEW 

Confute  time  correction  term 

DEKTR  =  F*ES*SAS*SIN{E) 

AFO  =  EPHEMdNVERS  (ISVNO)  ,7) 

AFl  =  EPHEM(INVERS{ISVNO) ,6) 

AF2  =  EPHEMdNVERSdSVNO)  ,5) 

TGD  =  EPHEMdNVERSdSVNO)  ,3) 

TOC  =  EPHEMdNVERS  (ISVNO)  ,4) 

BELT  =  AFO  +  AFl* (TC  -  TOC)  + 

AF2*(TC  -  TOC)''2  +  DELTR  -  TGD 

T  =  TC  -  BELT 
R  =  AS*  (1.0  -  ES*SIN(E) ) 

Compute  satellite  true  anomaly,  NU 

NUM  =  SQRTd.O  -  ES*ES)  *SIN(E)  )  / 
(1.0  -  ES*COS(E)) 

DENOM  =  (COS(E)-ES)/(1.0-ES*COS(E)) 
NU  =  ATAN2 (NUM,  DENOM) 

W  =  EPHEMdNVERS  (ISVNO)  ,21) 

PHI  =  NU  +  W 


Eccentricity  anomaly 

Relativistic  correction  term 

7  - 
6  - 
5  - 

3  - 

4  - 

Transit  time 

GPS  time  of  transmission  correction 
Satellite  average  radius  R 

Sin (true  anomaly) 

Cos (true  anomaly) 

Four  quadrant  inverse  tangent 
Argument  of  perigee  [semicircle] 
Argument  of  latitude 


Confute  correction  terms  from  harmonics 


CUS  =  EPHEMdNVERSdSVNO)  ,13) 

cue  =  EPHEMdl^VERS  (ISVNO)  ,11) 

CRS  =  EPHEMdNVERS  (ISVNO)  ,  8) 

OMEGAO  =  EPHEMdNVERSdSVNO)  ,  17) 

CIS  =  EPHEMdNVERSdSVNO)  ,18) 

CRC  =  EPHEMdNVERS  (ISVNO)  ,20) 

CIC  =  EPHEMdNVERS  (ISVNO)  ,  16) 

IOTA  =  EPHEMdNVERSdSVNO)  ,19) 

IDOT  =  EPHEMdNVERS  (ISVNO)  ,23) 

C2PHI  =  COS(2*PHI) 

S2PHI  =  SIN(2*PHI) 

Second  harmonic  perturbations 
DELPHI  =  CUS*S2PHI  +  CUC*C2PHI 
DELR  =  CRS*S2PHI  +  CRC*C2PHI 
DELI  =  CIS*S2PHI  +  CIC*C2PHI 


Amplitude  of  sine  harmonic  correction 
term  to  the  argument  of  latitude  [rad] 

Amplitude  of  cos  harmonic  correction 
term  to  the  argument  of  latitude  [rad] 

Amplitude  of  sine  harmonic  correction 
term  to  orbit  radius  [m] 

Longitude  of  ascending  node  of  orbit 
plane  at  weekly  epoch 

Amplitude  of  sine  harmonic  correction 
term  to  the  angle  of  inclination  [rad] 

Amplitude  of  cos  harmonic  correction 
term  to  the  orbit  radius  [m] 

Amplitude  of  cos  harmonic  correction 
term  to  the  angle  of  inclination  [rad] 

Inclination  angle  at  reference  time 
[semicircle] 

Rate  of  inclination  angle  [semicir/s] 
Double  angle 


Argument  of  latitude  correction 
Radius  correction 
Corrected  inclination 
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PHI  =  PHI  +  DELPHI 
R  =  R  +  DELR 

IOTA  =  IOTA  +  DELI  +  IDOT* (T-TOE) 

OMEGAD  =  EPHEMdNVERS  (ISVNO)  ,22) 
OER  =  OMEGAO  +  OMEGAD* (T-TOE)  - 
OMEGAE*T 


Corrected  argument  of  latitude 
Corrected  radius 
Corrected  inclination 

Rate  of  right  ascension  [semicircle/s] 
Corrected  longitude  of  ascending  node 


Confute  satellite  ECEF  vector  (meters) 

ECEFXS(L)  =  R*COS{OER)*  COS (PHI ) -R*SIN (OER) *COS ( IOTA) *SIN (PHI ) 
ECEFYS(L)  =  R*SIN(OER)*  COS (PHI ) +R*COS (OER) *COS ( IOTA) *SIN (PHI ) 
ECEFZS(L)  =  R*SIN (IOTA) *SIN (PHI) 
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3.1.1.2.5  XFORM_NAV_COORD 

The  responsibility  of  XFORM_NAV_COORD  is  to  extrapolate  both  self  and  master  navigation 
solution  into  ECEF  coordinates  and  local  level  coordinate  values.  This  process  will  be  involved 
for  both  self  and  master  navigation  solutions. 


INPUTS 

DESCRIPTION 

MS  IND 

MASTER/SLAVE  indicator 

NAVTOV 

Time  of  Validity  of  MASTER  Navigation  solution 

LAT 

Latitude  position  [rad] 

LATR 

Latitude  rate  [rad/s] 

LON 

Longitude  position  [rad] 

LONR 

Longitude  rate  [rad/s] 

ALT 

Altitude  [m] 

ALTR 

Altitude  rate  [m/s] 

OUTPUTS 

DESCRIPTION 

LLPX 

Local  level  x-coordinate  value 

LLPY 

Local  level  y-coordinate  value  LLP 

LLPZ 

Local  level  z -coordinate  value 

TLE  (3,3) 

Local  Level  transformation  matrix 

Stored  Constants: 


ar  =  2.09257382  E7 
e22  =  6.74499984  E-3 


Earth  semi -minor  radius  [ft] 
Earth  eccentricity  squared 
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SLAVE 


Q  START  ^ 


1 

r 

EXTRAPOLATE 

NAVIGATION 

TO 

TIME  OF 

GPS  MEASURE 

r 

COMPUTE 

ECEF 

POSITION 

r 

c 


MASTER 

r 

COMPUTE 
TRANSFORMATION 
MATRIX  BETWEEN 
ECEF&LL@ 
MASTER  POSITION 

. w 

f 

COMPUTE 

PLATFORM 

LOCAL 

LEVEL 

COORDINATES 

r 

EXIT 


) 


NOTE:  X  —  Latitude 
(|)  —  Longitude 
h  —  Altitude 


—  Latitude  Rate 
^  —  Longitude  Rate 
h°  —  Altitude  Rate 


i  =  A  +  1*7, 


=  ^  +  ^*  7. 


h  =  h  +  h*T, 


REw=  ar/^ll-e22  *sin^  A 
ECEFXP  =  (REW  +  h)*  COS  (X)*  COS  ( ^ ) 
i  ECEFYP  =  (REW  +  A)*COS(i)*SlN(^) 
ECEFZP  =  [(1-  e22)  *  REW  +  h  ] 


SL=SIN(.l) 

CL=C0S(A) 

SP  =  SIN(^) 

CP  =  COS(^) 

TLE(1,1)  =  -SL*CP 

TLE  (2,1)=  SP 

TLE(3,1)=CL*CP 

TLE(1,2)  =  -SL*SP 

TLE  (2,2)  = -CP 

TLE(3,2)  =  CL*SP 

TLE(1,3)  =  CL 

TLE  (2,3)  =  0 

TLE(3,3)  =  SL 

LLP  =  [TLEr 


ECEFXP 

ECEFYP 

ECEFZP 


where 

Up  =  LLPX,  LLPY,  LLPZ 


*  Note:  Master  Solution  must  be  called  first,  since  [TLE]  is  referenced  to  Master  position 


Figure  3.1-18:  XFORM_NAV_COORD  Logical  data  flow  diagram 
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3.1.1.2.6  CO]VIPUTE_LAB_SAT_VIS 

COMPUTE_LAB_SAT_VIS  restricts  DGPS  satellite  usage  to  set  of  satellites  at  least  5  degrees 
above  the  horizon.  This  SLXTSC  performs  the  computation  of  satellite  direction  cosines  CXS, 
CYS,  CZS  for  all  candidate  satellites.  This  block  also  computes  predicted  and  true  pseudorange 
values  between  master  and  self  to  all  selected  satellites 


INPUTS 

DESCRIPTION 

NVS 

Number  visible  satellites  -  common  to  MASTER  and  SELF 

SAT(NVS) 

Ordered  array  of  common  visible  satellites 

ECEFXS(K) 

ECEF  x-coordinate  for  satellite  K 

ECEFyS(K) 

ECEF  y-coordinate  for  satellite  K 

ECEFZS(K) 

ECEF  z-coordinate  for  satellite  K 

MLLPX 

ESTIMATED  MASTER  local  level  X- coordinate  value 

MLLPY 

ESTIMATED  MASTER  local  level  y- coordinate  value 

MLLPZ 

ESTIMATED  MASTER  local  level  z-coordinate  value 

SLLPX 

ESTIMATED  SLAVE  local  level  x- coordinate  value 

SLLPY 

ESTIMATED  SLAVE  local  level  y-coordinate  value 

SLLPZ 

ESTIMATED  SLAVE  local  level  z-coordinate  value 

TMLLPX 

TRUE  MASTER  local  level  x-coordinate  value 

TMLLPY 

TRUE  MASTER  local  level  y-coordinate  value 

TMLLPZ 

TRUE  MASTER  local  level  z-coordinate  value 

TSLLPX 

TRUE  SLAVE  local  level  x-coordinate  value 

TSLLPY 

TRUE  SLAVE  local  level  y-coordinate  value 

TSLLPZ 

TRUE  SLAVE  local  level  z-coordinate  value 

TLE  0 

Local  Level  transform  matrix 

XA{k) 

Refinement  Filter  solution  vector,  k  =  1,7 

OXJTPUTS 

DESCRIPTION 

SCOtMT 

Final  number  of  paired  satellites  visible  above  ANGLIM 

SATVIS (SCOUNT) 

Ordered  array  of  common  visible  satellites  above  ANGLIM 

EMPR(SCOUNT) 

PREDICTED  Pseudorange  Vector  to  satellites  from  MASTER 

ESPR (SCOUNT) 

PREDICTED  Pseudorange  Vector  to  satellites  from  SELF 

TMPR (SCOUNT) 

TRUE  Pseudorange  Vector  to  satellites  from  MASTER 

TSPR (SCOUNT) 

TRUE  Pseudorange  Vector  to  satellites  from  SELF 

CXS (SCOUNT) 

Direction  cosine  x-component 

CYS (SCOUNT) 

Direction  cosine  y- component 

CZS (SCOUNT) 

Direction  cosine  z- component 

Stored  Constants: 


ANGLIM  =  5  degrees 


Angle  of  inclination  that  marks  the 
boundary  of  visibility  [rad] 
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► 


Figure  3.1-19:  COMPUTE_SAT_LAB_VIS  Logical  data  flow  diagram 
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i  ESPR  (SCOUNT)  =  [DIFF2  (1 )  ^  +  DIFF2  (2)  ^  +  DIFF2  (3) 


i  EMPR  (SCOUNT)  =  [DIFFl  (1)^  +  DIFFl  (2)^  +  DIFFl  (3)^]''^ 


:  CXS  (SCOUNT)  =  DIFF2(1)/ ESPR 
I  CYS  (SCOUNT)  =  DIFF2  (2) /ESPR 
I  CZS  (SCOUNT)  =  DIFF2  (3) /ESPR 


;  DIFF2(1)  =  LLSATX-TSLLPX  j 

i  DIFF2(2)  =  LLSATY-TSLLPY 

j  DIFF2(3)  =  LLSATZ-TSLLPZ  ! 


'  DIFFl  (1)  =  LLSATX-TMLLPX 
I  DIFFl  (2)  =  LLSATY-TMLLPY 
:  DIFFl  (3)  =  1XSATZ-TMLLPZ 


I - 

i  TSPR  (SCOUNT)  =  [DIFF2  (1) ^  +  DIFF2  (2)  ^  +  DIFF2  (3)^]*'^ 


!  TMPR  (SCOUNT)  =  [DIFFl  (1)  ^  +  DIFFl  (2)  ^  +  DIFFl  (3) 

i 


Figure  3.1-20;  COMPUTE_SAT_LAB_VIS  Logical  data  flow  diagram  (cont.) 
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3.1.1.2.7  PROCESS_PR_DATA 

PROCESS_PR_DATA  performs  a  conversion  of  satellite  codephase  data  to  generate  an  array  of 
pseudorange  data  between  the  master  or  self  and  common  visible  satellites. 


INPUTS 

DESCRIPTION 

SCOUNT 

Final  paired  satellite  count  satisfying  elevation 

criteria 

SATVISlK),  K  =  1, SCOUNT 

Satellite  Visibility  vector 

NVS 

Number  of  satellites  paired,  but  not  yet  checked  for 

elevation 

MS  IND 

Master/Slave  data  indicator 

PRRl(j),  j=l,NVS 

MASTER  sorted  code  phase  data 

PRR2(j),  j=l,NVS 

SELF  sorted  code  phase  data 

MPGPSTM(j),  j=l,NVS 

MASTER  sorted  predicted  GPS  time  vector 

SPGPSTM(j),  j=l,NVS 

SELF  sorted  predicted  GPS  time  vector 

OUTPUTS 

DESCRIPTION 

EMPR(K) 

MASTER  predicted  pseudorange  vector  [m] 

ESPR(K) 

SELF  predicted  pseudorange  vector  [m] 

Stored  Constants: 


C  =  2.99792498  E8  [m/s] 
CR  =  TBD 


Speed  of  light 

Code  Phase  conversion  constant 
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Figure  3.1-21:  PROCESS_PR_DATA  Logical  data  flow  diagram 
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3.1.1.2.8  GENERATE_KALMAN_OBS_SET 

GENERATE_KALMAN_OBS_SET  generates  the  Refinement  Filter  measurement  array,  Y,  and 
the  expected  measurement  array,  YEXP.  The  SLCSC  also  generates  the  appropriate  observation 
matrix,  [H]  from  the  array  of  visible  satellites.  This  routine  shall  be  capable  of  supporting  both 
primary  mode  (DGPS)  observations,  as  well  as  the  backup  (PPLI/RTT)  mode. 


INPUTS 

DESCRIPTION 

SCOUNT* 

Number  of  selected  observations 

EMPR (SCOUNT) * 

EST (predicted)  pseudorange  array  from  MASTER 

ESPR (SCOUNT) * 

EST (predicted)  pseudorange  array  from  SELF 

TMPR (SCOUNT) * 

TRUE (measured)  pseudorange  array  from  MASTER 

TSPR (SCOUNT) * 

TRUE (measured)  pseudorange  array  from  SELF 

SATVIS(K)*,  K  =  1,  NS 

Satellite  Visibility  vector 

MLLPX 

ESTIMATED  MASTER  local  level  X- coordinate  value 

MLLPY 

ESTIMATED  MASTER  local  level  y- coordinate  value 

MLLPZ 

ESTIMATED  MASTER  local  level  z- coordinate  value 

SLLPX 

ESTIMATED  SLAVE  local  level  x-coordinate  value 

SLLPY 

ESTIMATED  SLAVE  local  level  y- coordinate  value 

SLLPZ 

ESTIMATED  SLAVE  local  level  z- coordinate  value 

TMLLPX 

TRUE  MASTER  local  level  x-coordinate  value 

TMLLPY 

TRUE  MASTER  local  level  y- coordinate  value 

TMLLPZ 

TRUE  MASTER  local  level  z- coordinate  value 

TSLLPX 

TRUE  SLAVE  local  level  x-coordinate  value 

TSLLPY 

TRUE  SLAVE  local  level  y- coordinate  value 

TSLLPZ 

i 

TRUE  SLAVE  local  level  z- coordinate  value 

BPR2M** 

Backup  measured  range  to  master 

BBC2M** 

Backup  measured  clock  bias  to  master 

TC 

Observation  set  time  of  validity 

RF_STATE 

State  of  the  refinement  filter 

X(A)  ,  A  =  1,  8 

Current  RF  state  vector 

CXS (SCOUNT) 

Direction  cosine  x- component 

CYS (SCOUNT) 

Direction  cosine  y- component 

CZS (SCOUNT) 

Direction  cosine  z- component 

OUTPUTS 

DESCRIPTION 

HA{12,8) 

Observation  matrix  for  Kalman  Filter 

YA(14) 

Inputs  to  the  Kalman  Filter 

YAEXP(14) 

Expected  Kalman  solutions 

SCOUNT 

Number  of  selected  observations 

TC 

Observation  set  time  of  validity 

SATVIS{K)*,  K  =  1,  NS 

Satellite  Visibility  vector 

DXTRUE 

TRUE  Error  composite  x-coordinate  value 

DYTRUE 

TRUE  Error  composite  y-coordinate  value 

DZTRUE 

TRUE  Error  composite  z- coordinate  value 

*  Required  when  CSCI_VERS_ID  =1,2,  or  3  (primary  mode  only) 
**  Required  when  CSCI_VERS_ID  =  4  (Backup  Mode) 

Stored  Constants: 


C  =  0.299792498  [m/ns] 


Speed  of  light 
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3.1.1.3  RF_KALMAN_PROC 

This  CSC  performs  the  extended  Kalman  Filter  (EKF)  processing  needed  to  estimate  the  numeric 
values  of  the  eight  Refinement  Filter  Error  terms  as  follows: 

XA(1):  LL  x-coordinate  relative  position  error  [m] 

XA(2):  LL  x-coordinate  relative  position  error  rate  [m/s] 

XA(3):  LL  y-coordinate  relative  position  error  [m] 

XA(4):  LL  y-coordinate  relative  position  error  rate  [m/s] 

XA(5):  LL  z-coordinate  relative  position  error  [m] 

XA(6):  LL  z-coordinate  relative  position  error  rate  [m/s] 

XA(7):  Relative  clock  bias  [ns] 

XA(8):  Relative  frequency  drift  [ns/s] 


As  part  of  the  operation  of  the  Kalman  Filter,  RF_KALMAN_PROC  shall  also  perform  the 
initialization  of  the  EKF  matrix  elements. 


Figure  3.1-23:  RF_KALMAN_PROC  Level  1  Breakdown 
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CSC  INPUTS 

DESCRIPTION 

KALMAN  OBS  SET 

HA(12,8) 

Observation  matrix 

SCOUNT 

Final  number  of  paired  satellites  visible  above  ANGLIM 

YAd),  I  =  1,  14 

Observation  measurement  vector 

YAEXPd),  1  =  1,  14 

Observation  prediction  vector 

TC,  TOLD 

Reference  time  at  which  measurements  are  valid  since  GPS 

time  of  week  [s] 

SATVIS(j) , 

Ordered  array  of  common  visible  satellites  above  ANGLIM 

j  =  1,  SCOUNT 

DXTRUE 

True  XYZ  direction  error  composites.  Only  used  when 

DYTRUE 

CSCI  VERS  ID  =  2.0  (Laboratory  Mode) 

DZTRUE 

BCTRUE 

True  clock  bias 

FCTRUE 

True  f recfuency  drift . 

PPLI_DATA 

Used  only  when  the  RF  State  is  in  Backup  Mode  (when  GPS 

RTT  DATA 

is  either  not  on  or  valid) .  Contains  pseudo  range  data 

RF  STATE 

Indicates  the  state  value  of  the  refinement  filter 

RSI 

Refinement  Status  Indicator 

Table  3.1-7:  RF_KALMAN_PROC  Inputs 


CSC  OUTPUTS 

DESCRIPTION 

RF__KALMAN_RESULTS_PKG 

TC 

RF_STATE 

RSI 

XA(k)  ,  k  =  1,  8 

SIGX 

SIGY 

SIGZ 

SIGBC 

SIGFC 

ERRX 

ERRY 

ERRZ 

ERRBC 

ERRFC 

Observation  set  time  of  validity 

Indicates  the  state  value  of  the  refinement  filter 
Refinement  Filter  Status  Indicator 

Refinement  Filter  Solution  Vector 

COVARIANCE  DIAGONAL  TERMS 

ERROR  TERMS 

SCOUNT 

Final  number  of  paired  satellites  visible  above  ANGLIM 

SATVIS{j)  , 

j  =  1,  SCOUNT 

Ordered  array  of  common  visible  satellites  above  ANGLIM 

Table  3.1-8:  RF_KALM AN_PROC  Outputs 
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Stored  Constants: 

POS  =  (1000.0) **2 
BCX  =  (100.0) **2 

PCX  =  (10.0) **2 

PNX  =  (1000.0)**2 
BCPNX  =  (10.0)**2 
FCPNX  =  (1.0) **2 

RNX  =  (21.0)**2 

RNX2  =  (12.5)**2 

RNX3  =  (4.0)**2 

SSLIM  =  TBD 


Initial  Position  Covariance  Constant  [m2] 

Initial  Clock  Bias  Covariance  Constant  [ns2] 
Initial  Freq  Drift  Covariance  Constant  [ns2/sec2] 
Process  Noise  Position  Constant  [m2] 

Process  Noise  Clock  Bias  Constant  [ns2] 

Process  Noise  Freq  Drift  Constant  [ns2/sec2] 

Range  Measurement  Variance  Constant  [m2] 

RTT  Clock  Bias  Measurement  Variance  Constant 
[ns  2] 

DGPS  Measurement  Variance  Constant  [m2] 

Steady  State  Indication  [m] 
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TRANSITION 
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OA(7,8)  =  At 
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1 
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1 _ 

_ 

6 

1 

r 

7 
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8 

1 

TIMEEXTI 
COVAIi 
SINCE  LAS 

- i 

UPOLATE 

aANCE 

T  UPDATE 

1 - 

■  P(t  +  At)  =  OP(t)<I>  W  [QA}  i 

L .  . . 1 

ZERO  STATE  VECTOR 
ELEMENT 
XA(k)  =  0.0k=l,8 


i.  ZERO  STATE 
COVARIANCE 
PA(i,j)=0.0  ij  =  l,8 


j- 


k. 


SET  COVARIANCE 
DIAGONAL  TERMS 
PA(I,1)=  POSX 
PA(3,3)=  POSX 
PA(5,5)=  POSX 
PA(7,7)=  BCX 
PA(8,8)=  PCX 

ZERO  PROCESS  NOISE 
MATRIX 

Q(i,j)  =  0.0  i,j=:l,8 


1.  SET  PROCESS  NOISE 
DIAGONAL  TERMS 
QA(1,1)=  PNX 
QA(3,3)=  PNX 
QA(5,5)=  PNX 
QA(7,7)=  BCPNX 
QA(8,8)=  FCPNX 


m.  ZERO  OBSERVATION 
NOISE  MATRIX 
RA(I2,12) 

n,  SET 
RA(1,1)=  RNX 
RA(2,2)=  RNX2 
PA(k,k)=  RNX3 
k  =  3, 12 


Figure  3.1-24:  RF_KALMAN_PROC  Logical  data  flow  diagram 
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Figure  3.1-25:  RF_KALMAN_PROC  Logical  data  flow  diagram  (cont) 
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COMPUTE 
COVARIANCE 
DIAGONAL 
SQUARE  ROOTS 


SIGX  =DSQRT(PA(1, 1)) 
SIGY  =DSQRT(PA(3,3)) 
SIGZ  =DSQRT(PA(5,5)) 
SIGBC  =  DSQRT  (PA  (7, 7)) 
SIGFC  =  DSQRT  (PA  (8, 8)) 


CHECK  FOR  STEADY 
STATE  ACHEIVED 


METRIC  =  DSQRT  (PA  (1,1)+  PA  (3, 3) 
+  PA  (5, 5)) 


METRIC  < 
SSLIM? 


RESET 

RF  STATE  =  4 


SET 

RF.STATUS 
INDICATOR  =  4 


SET 

RF.STATUS 
INDICATOR  =  5 


ASSEMBLE 

RF_KALMAN_ 

RESULTS.PKG 


TIME  (TC) 

RF_STATE 

RF_STATUS_INDICATOR 
XA  STATE  VECTOR  VALUES 
COVARIANCE  DIAGONAL  TERMS 
ERROR  TERMS 
SCOUNT 

SATVIS  (SCOUNT) 


Figure  3.1-26:  RF_KALMAN_PROC  Logical  data  flow  diagram  (cont) 
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3.1.1.4  OCP_INT_PROC 


The  OCP  Interface  Processing  provides  a  two-way  interface  between  the  Link  16  Operational 
Software  and  Refinement  Filter  Processing.  This  SLCSC  processes  received  Master  Message 
Data  and  produces  appropriate  Master  Data  Package  for  further  processing  within  the  refinement 
filter.  It  also  processes  the  self-navigation  solution  to  produce  an  appropriate  self-navigation 
data  package  to  further  processing  within  the  Refinement  Filter. 


Figure  3.1-27:  OCP_INT_PROC  Level  1  Breakdown 
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CSC  Inputs 

Description 

CSCI_VERS_IND 

Denotes  Operational  Version 

RF__STATE 

Indicates  the  state  value  of  the  refinement  filter 

MASTER_MSG_ 

This  message  contains 

Master's  nav  solution 
master's  GPS  data 

PPLI_DATA 

RTT__DATA 

Used  only  when  the  RF  State  is  in  Backup  Mode 
(when  GPS  is  either  not  on  or  valid) .  Contains 
pseudo  range  data 

EST_SNAV 

ESTIMATED  SELF  Navigation  Data 

TRUE_SNAV_ 

TRUE  SELF  Navigation  Data 

TRUE_MNAV 

TRUE  MASTER  Navigation  Data 

SNAV_VAL_IND 

Self  Navigation  Validity  Indicator 

MNAV__VAL_IND 

Master  Navigation  Validity  Indicator 

MS_IND 

Master/Slave  Indicator 

MMS 

Master  Message  Prepared  Signal 

RF_RESULTS_DATA 

Refinement  Filter  corrections  and  covariance  to 
send  to  AF  (used  when  CSCI  =  4,  Backup  Mode) 

CSC  Outputs 

Description 

PPLI  DATA 

Used  only  when  the  RF  State  is  in  Backup  Mode 

RTT_DATA 

(when  GPS  is  either  not  on  or  valid) .  Contains 
pseudo  range  data 

MNAV_DATA 

MASTER  Navigation  Solution 

SNAV_DATA 

SELF  Navigation  Solution 

RF_RESULTS_MSG 

Refinement  Filter  corrections  and  covariance  to 
send  to  AF 

MASTER_MSG 

This  message  contains 

Master's  nav  solution 

Master's  GPS  data 

MS_IND 

Master/Slave  Indicator 

MMS 

Master  Message  Prepared  Signal 

SNAV_VAL_IND 

Self  Navigation  Validity  Indicator 

MNAV_VAL_IND 

Master  Navigation  Validity  Indicator 

CSCI_VERS_IND 

Denotes  Operational  Version 
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INPUTS 

DESCRIPTION 

MS  IND 

MASTER/SLAVE  Indicator 

LF  IND 

LABORATORY/FIELD  Indicator 

MASTER  MSG 

Received  MASTER  Message 

MMS 

MASTER  Message  Signal 

TRUE  MASTER  NAV  DATA 

TMNAVTOV 

TRUE  Time  of  Validity  of  MASTER  Navigation  solution 

TMLAT 

TRUE  MASTER  Latitude  position  [rad] 

TMNVEL 

TRUE  MASTER  North  Velocity  [ft/s] 

TMLON 

TRUE  MASTER  Longitude  position  [rad] 

TMEVEL 

TRUE  MASTER  East  Velocity  [ft/s] 

TMALT 

TRUE  MASTER  Altitude  [ft] 

TMALTR 

TRUE  MASTER  Altitude  rate  [ft/s] 

ESTIMATED  SELF  NAV  DATA 

SNAVTOV 

Time  of  Validity  of  SELF  Navigation  solution 

SLAT 

ESTIMATED  SELF  Latitude  position  [rad] 

SNVEL 

ESTIMATED  SELF  North  Velocity  [ft/s] 

SLON 

ESTIMATED  SELF  Longitude  position  [rad] 

SEVEL 

ESTIMATED  SELF  East  Velocity  [ft/s] 

SALT 

ESTIMATED  SELF  Altitude  [ft] 

SALTR 

ESTIMATED  SELF  Altitude  rate  [ft/s] 

TRUE  SELF  NAV  DATA 

TSNAVTOV 

TRXra:  Time  of  Validity  of  SELF  Navigation  Solution 

TSLAT 

TRUE  SELF  Latitude  position  [rad] 

TSNVEL 

TRUE  SELF  North  Velocity  [ft/s] 

TSLON 

TRUE  SELF  Longitude  position  [rad] 

TSEVEL 

TRUE  SELF  East  Velocity  [ft/s] 

TSALT 

TRUE  SELF  Altitude  [ft] 

TSALTR 

TRUE  SELF  Altitude  rate  [ft/s] 

BCTRUE 

TRUE  Clock  Bias 

FCTRUE 

TRUE  Frequency  Drift 
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OUTPUTS 

DESCRIPTION 

MNAV  DATA  PACKAGE 

MNAVTOV 

Time  of  Validity  of  MASTER  Navigation  solution 

MLAT 

ESTIMATED  MASTER  Latitude  position  [rad] 

MLATR 

ESTIMATED  MASTER  Latitude  rate  [rad/s] 

MLON 

ESTIMATED  MASTER  Longitude  position  [rad] 

MLONR 

ESTIMATED  MASTER  Longitude  rate  [rad/s] 

MALT 

ESTIMATED  MASTER  Altitude  [m] 

MALTR 

ESTIMATED  MASTER  Altitude  rate  [m/s] 

TMLAT 

TRUE  MASTER  Latitude  position  [rad] 

TMLATR 

TRUE  MASTER  Longitude  rate  [m/s] 

TMLON 

TRUE  MASTER  Longitude  position  [rad] 

TMLONR 

TRUE  MASTER  Longitude  rate  [m/s] 

TMALT 

TRUE  MASTER  Altitude  [m] 

TMALTR 

TRUE  MASTER  Altitude  rate  [m/s] 

MSAT{12) 

Master  Ordered  Satellite  List 

MPRR(12) 

Master  Ordered  Measured  Code  Phase  Array 

MGPSTOV 

MASTER  predicted  GPS  time  of  validity 

MVIS 

Number  of  satellites  visible  to  MASTER 

INVERSOO) 

Satellite  sorting  index 

SNAV  DATA  PACKAGE 

SNAVTOV 

Time  of  Validity  of  SELF  Navigation  solution 

SLAT 

ESTIMATED  SELF  Latitude  position  [rad] 

SLATR 

ESTIMATED  SELF  Latitude  rate  [rad/s] 

SLON 

ESTIMATED  SELF  Longitude  position  [rad] 

SLONR 

ESTIMATED  SELF  Longitude  rate  [rad/s] 

SALT 

ESTIMATED  SELF  Altitude  [m] 

SALTR 

ESTIMATED  SELF  Altitude  rate  [m/s] 

TSLAT 

TRUE  SELF  Latitude  position  [rad] 

TSLATR 

TRUE  SELF  Latitude  rate  [rad/s] 

TSLON 

TRUE  SELF  Longitude  position  [rad] 

TSLONR 

TRUE  SELF  Longitude  rate  [rad/s] 

TSALT 

TRUE  SELF  Altitude  [m] 

TSALTR 

TRUE  SELF  Altitude  rate  [m/s] 

SNAV_VAL_IND 

Self  Navigation  Validity  Indicator 

MNAV  VAL  IND 

Master  Navigation  Validity  Indicator 

Stored  Constants: 

=  2.09257382  E7 
=  57.295779513 


ar  ! 
rad 


Earth  semi -minor  radius  [ft] 
radians  [rad] 
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c 


EXIT 


> 


CALLPROCESS_  i 
MASTER 
MESSAGE 

1 

r 

CALL 

PROCESS_RAW_ 
GPS  DATA 

y 

r 

CALL 

CONVERT_NAV_ 

DATA 

(MASTER  ESTDATA) 

1 

y 

r 

CALL 

CONVERT  NAV_ 
DATA 

(SELF  ESTDATA) 

DECOMPOSE  MASTER  MESSAGE  INTO 
N A V  DATA  AND  GPS  DATA 


ORDER  GPS  DATA 
OUTPUTS 


■ 

MSAT 

■ 

MPRR 

■ 

MGPSTOV 

■ 

MVIS 

■ 

INVERS  (30) 

OUTPUT : 


MNAVTOV 
MLAT 
MLATR 
MLON 
MLONR 
MALT 
MALTR 


OUTPUT 

i 

1  ■ 

SNAVTOV 

j 

■ 

1 

SLAT 

I  ^ 

SLATR 

i 

i 

SLON 

1 

■ 

SLONR 

t  1 

SALT 

i 

i 

SALTR 

j 

Figure  3.1-28:  OCP_INT_PROC  Logical  data  flow  diagram 
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OUTPUT: 


1  ■ 

MNAVTOV 

■ 

TMLAT 

;  ■ 

TMLATR 

1  B 

TMLON 

B 

TMLONR 

!  ■ 

TMALT 

j  B 

TMAT.TR 

OUTPUT :  1 

SNAVTOV 

■  TSLAT  ! 

■  TSLATR  j 

■  TSLON 

■  TSLONR  I 

■  TSALT  j 

■  tSALTR 

■  BCTRUE  I 

■  FCTRUE  : 


Figure  3.1-29:  OCP_INT_PROC  Logical  data  flow  diagram  (coni.) 
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3.1.1.4.1  PROCESS_MASTER_MSG 

PROCESS_MASTER_MSG  decomposes  the  received  Master  Message  Data  into  Master  NAV 
data  and  GPS  data 


INPUTS _ 

RECEIVED  MASTER  MESSAGE 


DESCRIPTION _ 

This  message  contains 


Master's  NAV  solution 


Master's  GPS  Data 


OUPUTS _ 

MASTER  NAV  SOLUTION 
MNAVTOV 
MLAT 
MNVEL 
MLON 
MEVEL 
MALT 
MALTR 

MASTER  GPS  DATA 
GPS__HEALTH_IND 
MGPSTOV 
UMSAT(12) 
UMPRR(12) 


DESCRIPTION 


Time  of  Validity  of  MASTER  Navigation  solution 
ESTIMATED  MASTER  Latitude  position  [rad] 

ESTIMATED  MASTER  North  Velocity  [ft/s] 

ESTIMATED  MASTER  Longitude  position  [rad] 
ESTIMATED  MASTER  East  Velocity  [ft/s] 

ESTIMATED  MASTER  Altitude  [ft] 

ESTIMATED  MASTER  Altitude  rate  [ft/s] 

Indicates  the  health  status  of  GPS  signal (Binary) 
Time  of  Validity  of  MASTER  GPS  Solution 
Unordered  array  of  MASTER  visible  satellites 
Unordered  array  of  MASTER  Code  Phase 
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3.1.1.4.2  PROCESS_RAW_GPS_DATA 

This  SLCSC  processes  the  GPS  data  decomposed  from  the  MASTER_MSG.  This  function 
produces  ordered  arrays  of  satellite  ID’s  and  code  phase  data.  The  IN  VERS  array  is  also 
generated  for  SOURCE_DATA_PROC. 


INPUTS 

DESCRIPTION 

USSAT(12) 

Unordered  array  of  MASTER  visible  satellites 

UMPRR(12) 

Unordered  array  of  MASTER  code  phase 

OUTPUTS 

DESCRIPTION 

MSAT(12) 

Ordered  array  of  MASTER  visible  satellites 

MPRR(12) 

Ordered  array  of  MASTER  code  phase 

INVERSOO) 

Satellite  sorting  index 

MVIS 

Number  of  Satellites  visible  to  the  MASTER 

Pseudocode: 

ZNVERS  array  generation 
DO  X  j  =  1,  12 

ID  =  MSAT[j] 
INVERS[ID]  =  j 

X  CONTINUE 


Insertion  sort  algorithm 

DO  y  j  =  1,  SAT. length  Loop  through  target  array  &  put  each 

item  in  the  proper  slot,  shifting  other 
items  out  of  the  way  as  you  go. 


ID  =  SATtj]  ; 

i  =  j  -  1; 

WHILE  (i  >=  0  &&  SAT[i]  >  ID) 

SAT[i+l]  =  SATti]; 
i  =  i-1; 

SAT[i]  is  the  item  that  should  precede 
value .  Put  value  after  it . 


SAT[i+l]  =  ID; 
Y  CONTINUE 


This  process  is  repeated  for  each  of  the  SELF  and  MASTER  satellite  ID  and  code  phase  data. 
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3.1.1.4.3  CONVERT_NAV_DATA 

This  SLCSC  converts  LI  6  Nav  data  into  metric  units.  CONVERT_NAV_DATA  also  generates 
Latitude  and  Longitude  Rate  terms. 


INPUTS 

DESCRIPTION 

NVEL 

North  Velocity  [ft/sec] 

EVEL 

East  Velocity  Rate  [ft/sec] 

ALT 

Altitude  [ft] 

ALTR 

Altitude  rate  [ft/s] 

OUPUTS 

DESCRIPTION 

LATR 

Latitude  rate  [rad/s] 

LONR 

Longitude  rate  [rad/s] 

ALT 

Altitude  [m] 

ALTR 

Altitude  rate  [m/s] 

Stored  Constants: 

ar  =  2.09257382  E7 

rad  =  57.295779513 

FT  M  =  3.28083991666  [ft/m] 


Earth  semi -minor  radius  [ft] 
radians  [rad] 

Feet  meters  conversion 


The  following  equations  is  used  to  convert  the  required  Navigation  data 

NVEL  =LATR  [rad  /s] 

ar[ft] 

EVEL[ft/s]_  ^  ^  LONR[rad  /  s] 

ar[ft]xcos(LAT) 


ALT  [ft] 


FT_M  [ft/m] 


=  ALTR  [m] 


ALTR  [ft/s] 
FT_M  [ft/m] 


=  ALTR  [m  /  s] 
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3.1.1.5  HOST_INT_PROC 


— ► 

RF_EXEC_CTRL 

4— 

1 

GPS_VAL_IND  RF_HEALTH_STATUS_MSG  RF_ENABLE 

(2,3,4)  (1,2, 3,4)  (2.3.41 


Figure  3.1-30:  HOST_INT_PROC  Level  1  Breakdown 


The  host  Interface  Processing  function  serves  as  the  primary  two  way  data  path  between  the 
DGPS  RF  algorithm  and  the  host  processor.  With  respect  to  input  from  the  host,  it  performs  the 
following  functions: 

(a)  Interprets  and  reformats  DGPS  RF  control  inputs  provided  by  the  host,  namely: 

-  RF_ENABLE  (Operate/Non-operate  switch) 

-  RF_OPR_SW  (Operator  command  algorithm  reset  indicator) 

(b)  Interprets  and  reformats  raw  input  provided  by  the  GPS  receiver,  including  GPS 
validity  indicator,  Self-GPS  pseudorange  measurements,  and  ephemeris  data. 

With  respect  to  host  output,  HOST_INT_PROC  is  responsible  for  providing  an  RF  Health  and 
Status  Message,  which  includes  the  full  filter  state  estimates  and  co  variances  plus  RF  State  and 
Status  Indicators. 
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CSC  inputs  and  outputs  are  summarized,  respectively,  in  Tables  4.4.5- 1  and  4.4.5-2.  Two 
SLCSCs  are  utilized  within  HOST_INT_PROC.  Their  functions  are  described  in  Table  4.4.5-3. 


CSC  Inputs 

Version 

Description 

RF_OPR_SW 

1,2, 3, 4 

Operator  Reset  Command 

RF_ENABLE 

2,3,4 

RF  Enable  Command 

SELF_GPS_DATA_ 

2,3,4 

Pseudorange  and  satellite  ID  message  data 

GPS_VAL_IND 

2,3,4 

GPS  Validity  Indicator 

EPHEM_RAW 

2,3,4 

Raw  Ephemeris  Data  message 

RF_HEALTH_STATUS_MSG 

2,3,4 

Summary  of  GPS  results  and  status 

Table  3.1-9:  HOST_INT_PROC  Input  Variables 


CSC  Outputs 

Version 

Description 

RF_HEALTH_STATUS_MSG 

Summary  of  GPS  results  and  status 

Table  3.1-10:  HOST_INT_PROC  Output  Variables 


EXTRACT. 

BUILD. 

GPS.PSEUDORANGE 

EPHEMERIS.TABLE 

Figure  3.1-31:  HOST_INT_PROC  Level  2  Breakdown 


SLCSC 

Description 

EXTRACT_GPS_PSEUDORANGE 

Decomposes  GPS  receiver  data  to  provide  an 
ordered  array  of  satellite  ID'S  and  code  phase 
data . 

BUILD_EPHEMERIS__TABLE 

Reformats  GPS  receiver  ephemeris  message  to 
provide  standard  ephemeris  array. 

Table  3.1-11:  HOST_INT_PROC  SLCSC  Descriptions 
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3.1.1.6  BUILD_MASTER_MSG 


SNAV  DATA  PKG  (2. 3,  4) 

- ^ 

OCP_ 

INT_ 

BUILD. 

HOST 

PROC 

MASTER 

^  GPS_PR_DATA  (2,  3,  4) 

INT 

MSG 

PROC 

^  MASTER.MSG  (2,  3,  4) 

Figure  3.1-32:  BUILD_MASTER_MSG  Level  1  Breakdown 


The  purpose  of  this  function  is  to  construct  outgoing  Master  Messages  containing  self  navigation 
and  measured  pseudorange  data  collected  at  own  location.  This  function  shall  be  invoked  only 
when  own  platform  hiis  been  designated  as  Master. 


The  contents  and  format  of  the  J28.7  Master  Message  are  presented  in  paragraph  4.5.4. 
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3.1.1.7  BUILD_RF_RESULTS_DATA 


Figure  3.1-33:  BUILD_RF_RESULTS_DATA  Level  1  Breakdown 


This  function  is  intended  as  a  place  holder  for  a  potential  enhanced  Version  4.0  of  the  DGPS  RF 
algorithm.  This  version  of  the  software  would  combine  the  functionality  of  the  DGPS  RF  with 
that  of  an  Atmospheric  Calibration  Filter  (AF),  now  being  developed  under  separate  contract. 
The  basic  concept  of  Version  4.0  is  to  improve  basic  Link- 16  navigation  performance  via 
advanced  atmospheric  calibration  of  TOA  range  measurements.  The  Atmospheric  Filter  utilizes 
the  position  estimates  of  the  transmitter  and  receiver  of  a  PPLI  message  as  basic  input.  The 
DGPS  RF  has  demonstrated  the  ability  to  reduce  errors  in  position  estimates  to  extremely  small 
levels.  These  precise  DGPS  RF  position  estimates  can  generate  a  corrective  term  that  will 
reduce  the  range  estimate  error  of  the  AF,  if  applied  to  the  existing  Link- 16  navigation  solution. 


The  purpose  of  Build_RF_Results_Data  is  to  package  the  error  estimates  of  the  DGPS  RF 
Kalman  Filter  for  transfer  to  the  Link- 16  OCP.  Note  that  this  function  exists  only  for  the 
Enhanced  Version  4.0  of  the  DGPS  algorithm. 
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MGPSTOV 

MLAT 

MLATR 

MLLPX 

MLLPY 

MLLPZ 

MLON 

MLONR 

MNAVTOV 

MNVEL 

MPGPSTM(NVS) 

MPRR{12) 

MS_IND 

MSAT(12) 

MVIS 

NAVTOV 

NVEL 

NVS 

OMEGAO (K) ,  K  =  1,  30 
OMEGAS  =  1.45858522  E-4 
OMEGE  =  7.292115467  E-5 
PGPSTM 
PRRl (NVS) 

PRR2 (NVS) 

RF__ENABLE 

RF_OPR_SW 

RF_STATE 

RF_STATUS_IND 

RK  =  87051108 

SALT 

SALTR 

SAT  (NVS) 

SATVIS  (SCOUNT) 

SCOUNT 

SELF_GPS_DATA 

SEVEL 

SGPSTOV 

SLAT 

SLATR 

SLLPX 

SLLPy 

SLLPZ 

SLON 

SLONR 

SNAVTOV 

SNVEL 

SPGPSTM(NVS) 


MASTER  predicted  GPS  time  of  validity 
ESTIMATED  MASTER  Latitude  position  [rad] 

ESTIMATED  MASTER  Latitude  rate  [rad/s] 

ESTIMATED  MASTER  local  level  x- coordinate  value 
ESTIMATED  MASTER  local  level  y-coordinate  value 
ESTIMATED  MASTER  local  level  z -coordinate  value 
ESTIMATED  MASTER  Longitude  position  [rad] 

ESTIMATED  MASTER  Longitude  rate  [rad/s] 

Time  of  Validity  of  MASTER  Navigation  solution 
ESTIMATED  MASTER  North  Velocity  [ft/s] 

MASTER  sorted  predicted  GPS  time  vector 
MASTER  Ordered  measured  code  phase  array 
MASTER/SLAVE  indicator 

MASTER  Ordered  array  of  visible  satellites 
Number  of  satellites  visible  to  MASTER 
Time  of  Validity  of  MASTER  Navigation  solution 
North  Velocity  [ft/sec] 

Number  visible  satellites  -  common  to  MASTER  and  SELF 
Lat  coordinates  of  satellites 
Satellite  orbital  rate  [rad/s] 

Earth's  rotational  rate  [rad/s] 

Predicted  GPS  time 

MASTER  array  of  code  phase  for  common  satellites 
SELF  array  of  code  phase  for  common  satellites 
ON/OFF  switch 

Reset/Initiate  signal  from  Host  pilot 
State  of  the  refinement  filter 

Refinement  filter  status  indicator 
Radius  of  satellite  orbit  [m] 

ESTIMATED  SELF  Altitude 

ESTIMATED  SELF  Altitude  rate 

Ordered  array  of  common  visible  satellites 

Ordered  array  of  common  visible  satellites  above  ANGLIM 

Final  number  of  paired  satellites  visible  above  ANGLIM 

Received  GPS  data  from  HOST 
ESTIMATED  SELF  East  Velocity  [ft/s] 

SELF  Predicted  GPS  time  of  validity 
ESTIMATED  SELF  Latitude  position  [rad] 

ESTIMATED  SELF  Latitude  rate  [rad/s] 

ESTIMATED  SLAVE  local  level  x- coordinate  value 
ESTIMATED  SLAVE  local  level  y- coordinate  value 
ESTIMATED  SLAVE  local  level  z- coordinate  value 
ESTIMATED  SELF  Longitude  position  [rad] 

ESTIMATED  SELF  Longitude  rate  [rad/s] 

Time  of  Validity  of  SELF  Navigation  solution 
ESTIMATED  SELF  North  Velocity  [ft/s] 

SELF  sorted  predicted  GPS  time  vector 
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SPRR(12) 

SELF  Ordered  measured  code  phase  array 

SSAT(12) 

SELF  Ordered  array  of  visible  satellites 

SVIS 

Number  of  satellites  visible  to  SELF 

TC 

Observation  set  time  of  validity  (GPS  system  time  [s] ) 

TLE{) 

Local  Level  transform  matrix 

TMALT 

TRUE  MASTER  Altitude 

TMALTR 

TRUE  MASTER  Altitude  rate 

TMEVEL 

TRUE  MASTER  East  Velocity  [ft/s] 

TMLAT 

TRUE  MASTER  Latitude  position  [rad] 

TMLATR 

TRUE  MASTER  Latitude  rate  [rad/s] 

TMLLPX 

TRUE  MASTER  local  level  x- coordinate  value 

TMLLPy 

TRUE  MASTER  local  level  y- coordinate  value  I 

TMLLPZ 

TRUE  MASTER  local  level  z- coordinate  value 

TMLON 

TRUE  MASTER  Longitude  position  [rad] 

TMLONR 

TRUE  MASTER  Longitude  rate  [rad/s] 

TMNVEL 

TRUE  MASTER  North  Velocity  [ft/s] 

TMPR(SCOUNT) 

TRUE  Pseudorange  Vector  to  satellites  from  MASTER 

TSALT 

TRUE  SELF  Altitude 

TSALTR 

TRUE  SELF  Altitude  rate 

TSEVEL 

TRUE  SELF  East  Velocity  [ft/s] 

TSLAT 

TRUE  SELF  Latitude  position  [rad] 

TSLATR 

TRUE  SELF  Latitude  rate  [rad/s] 

TSLLPX 

TRUE  SLAVE  local  level  x-coordinate  value 

TSLLPY 

TRUE  SLAVE  local  level  y-coordinate  value 

TSLLPZ 

TRUE  SLAVE  local  level  z -coordinate  value 

TSLON 

TRUE  SELF  Longitude  position  [rad] 

TSLONR 

TRUE  SELF  Longitude  rate  [rad/s] 

TSNVEL 

TRUE  SELF  North  Velocity  [ft/s] 

1  TSPR(SCOUNT) 

TRUE  Pseudorange  Vector  to  satellites  from  SELF 

1  UMPRR(12) 

Unordered  array  of  MASTER  code  phase 

1  UMSAT(12) 

Unordered  array  of  SELF  visible  satellites 

1  USPRR(12) 

Unordered  array  of  SELF  code  phase 

USSAT(12) 

Unordered  array  of  MASTER  visible  satellites 

XA(k) 

Refinement  Filter  Solution  Vector,  k  =  1,  8 

YA(14) 

Inputs  to  the  Kalman  Filter 

YAEXP(14) 

Expected  Kalman  solutions 

Appendix  B: 

Simulated  Code  Listing 
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c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


I 


SUBROUTINE  RF__EXEC_CTRL  (RF_OPR_SW,  MS_IND,  GPS_HEALTH_IND , 

RF_OUTPUT_DATA,  LF_IND,  SNAV_VAL_IND ,  MNAV__VAL_IND ,  DATA_STATUS__  MSG, 
CLK  BIAS_FREQ_DRIFT,  RTT_REQUEST_IND,  RF_STATE,  RF__HEALTH_STATUS_MSG) 


VERSION  NO.  1.0  DATE:  03  APRIL  2003 

PURPOSE:  TO  SERVE  AS  AN  EXECUTIVE  CONTROL  OF  THE  REFINEMENT  PROCESS.  THIS 

CSC  IS  THE  ONLY  INTERFACE  TO  THE  HOST_INTERFACE_PROC  AND  OCP__INT_PROC 


INPUTS : 


CRF_OPR_SW 

MS_IND 

GPS_HEALTH_IND 

RF_OUTPUT_DATA 

LF_IND 

SNAV_VAL_IND 

MNAV_VAL_IND 

DATA  STATUS  MSG 


-  ON/OFF  switch  for  system  initialization/reset 
Master/Slave  Indicator 

-  Indicates  the  health  status  of  GPS  signal 

-  Refinement  Filter  results  and  covariance,  XA  and  COV 
Laboratory/Field  Indicator 

Self  Navigation  Validity  Indicator 
Master  Navigation  Validity  Indicator 

-  Indicates  status  of  data  alignment  for  processing. 


OUTPUTS : 

CLK_BIAS_FREQ_DRIFT  -  Send  clock  bias  and  frequency  drift  data  if  requested 
RTT_REQUEST_IND  -  Send  request  for  RTT  and  PPLI  when  system  resides  in 

backup  mode. 

RF_STATE  -  Indicates  the  state  value  of  the  refinement  filter 

RF^HEALTH_STATUS_MSG  -  Determines  whether  the  filter  should  be  reset, 
switch  to  backup  mode,  or  system  normal. 


VERSION  1 


INPUTS:  TC,  T,  TLAT,  TLON,  TALT,  ELAT,  ELON,  EALT,  TLATR, 
TLONR,  TALTR,  ELATR,  ELONR,  EALTR,  CBIAS,  FDRIFT 


LOCAL  VARIABLES: 

RSI  -  RF  Status  Indicator 


GLOBAL  VARIABLES: 


CALLED  BY: 
RNS 


ROUTINES  CALLED: 
HOST_INT_PROC 
OCP_INT_PROC 
BUILD_MASTER_MSG 
RF_SOURCE_DATA_PROC 
RF  KALMAN  PROC 


C 

C  MODICATION  HISTORY: 
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c 


c 

c 

c 

c 
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VI.  0  ORIGINAL  VERSION  DATE  RESPONSIBLE 

FOR  VERSION  1.0  4/03/03  JYH 


C  SUBROOTINE  RF_EXEC_CTRL  (RF_OPR_SW,  MS_IND,  GPS_HEALTH_IND , 

C  1  RP_OUTPUT_DATA,  LF_IND,  SNAV_VAL_IND ,  MNAV_VAL_IND ,  DATA_STATUS_  MSG, 

C  2  CLK_BIAS_FREQ_DRIFT,  RTT_REQUEST_IND,  RF_STATE,  RF_HEALTH_STATUS_MSG) E 

SUBROUTINE  RF_EXEC_CTRL (TC,  TLAT,  TLON,  TALT,  ELAT,  ELON,  EALT,  TLATR,  TLONR, 
1  TALTR,  ELATR,  ELONR,  EALTR,  CBIAS,  FDRIFT) 


C 

C  DECLARATION  OF  VARIABLES 

C 


IMPLICIT  NONE 

! Inputs 

INTEGER* 4  RSI,  RF_STATE,  CSCI_VERS_IND 

INTEGER*4  RF_OPR_SW,  SNAV_VAL_IND ,  MNAV_VAL_IND ,  GPS_STRENGTH ,  SS 


INTEGER*4  SATVIS(12) 


INTEGER*4  MS_IND,  GPS_HEALTH_IND ,  RTT_REQUEST_IND ,  MVIS,  SVIS,  SCOUNT 


REAL* 8 
REAL* 8 


TC,  TOLD,  TLAT(IO),  TLON{10),  TALT(IO),  ELAT(IO),  ELON(IO),  EALT(IO) 

TLATR(IO),  TLONR(IO),  TALTR(IO),  ELATR(IO),  ELONR(IO),  EALTR (10) , CBIAS (10) ,  FDRIFT(IO) 


C 

C  SOURCE  DATA  VARIABLES 

C 


REAL* 8 
REAL* 8 
REAL* 8 
REAL* 8 
REAL* 8 
REAL* 8 
REAL* 8 


MSAT(12),  SSAT(12),  MPRR(12),  SPRR(12),  SAT(24), 
EPHEM(23,30) ,  INVERS(30),  ECEFXS(30),  ECEFYS(30), 
OMEGAO(24),  ETA0(24) 

TMGPSTOV,  TMNAVTOV,  TMLAT,  TMLATR,  TMLON,  TMLONR, 
TSGPSTOV,  TSNAVTOV,  TSLAT,  TSLATR,  TSLON,  TSLONR, 
MGPSTOV,  MNAVTOV,  MLAT,  MLATR,  MLON,  MLONR,  MALT, 
SGPSTOV,  SNAVTOV,  SLAT,  SLATR,  SLON,  SLONR,  SALT, 


PRR1(24),  PRR2(24) 

ECEFZS (30) 

TMALT,  TMALTR,  TMLLPX, TMLLPY, 
TSALT,  TSALTR,  TSLLPX, TSLLPY, 
MALTR,  MLLPX,  MLLPY,  MLLPZ 
SALTR,  SLLPX,  SLLPY,  SLLPZ 


TMLLPZ 

TSLLPZ 


REAL*8  MPGPSTM(24),  SPGPSTM(24) 

REAL*  8  TLE (3,3),  BCTRUE ,  FCTRUE 

REAL*8  ECEFS(3,1),  LLSAT(3,1),  LLSATX(24),  LLSATY(24),  LLSATZ(24) 

REAL*8  SDIFF(3),  MDIFF(3),  TSDIFF(3),  TMDIPF(3),  VIS(24) 

REAL*8  EMPR(12),  ESPR(12),  TMPR(12),  TSPR (12) , CXS (24) ,  CYS(24),  CZS(24) 


REAL*8  BPR2M,  BBC2M,  DXTRUE,  DYTRUE,  DZTRUE 

REAL* 8  MNVEL,  MEVEL,  TMNVEL,  TMEVEL,  SNVEL,  SEVEL,  TSNVEL,  TSEVEL 


C 


KALMAN  FILTER  VARIABLES 
***************************** ***** 


REAL*8  PHIA(8,8),  YA (12) , YAEXP (12) , XA(8 ) , HA (12 , 8) 
REAL*8  PA(8, 8) ,RA(12, 12) ,QA(8, 8) 
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•INTEGER* 4  POSX,  BCX,  PCX,  PNX,  BCPNX,  FCPNX,  RNX, 

REAL*8  IOTA,  OMEGE,  OMEGS,  RAD,  ANGLIM 


RNX2, 


RNX3,  NVS, 


I,  J 


DATA  POSX/1000000.0/ 
DATA  BCX/10000.0/ 
DATA  FCX/100.0/ 

DATA  PNX/1000000 .0/ 
DATA  BCPNX/ 10 0.0/ 
DATA  FCPNX/1.0/ 

DATA  RNX/441.0/ 

DATA  RNX2/156.25/ 
DATA  RNX3/1G.0/ 

C  DATA  SSLIM/TBD/ 


DATA  IOTA/ 5 5.0/ 

DATA  OMEGE, OMEGS/7. 292115467E-5, 1.45858522E-4/ 
DATA  RAD/57.2957795131/ 

DATA  ANGLIM/5.0/ 


DATA  CSCI_VERS_IND/1/ 
DATA  RP_OPR_SW/l/ 

DATA  MS_IND/2/ 

DATA  GPS_HEALTH_IND/1/ 
DATA  GPS_STRENGTH/1/ 

•DATA  SNAV_VAL_IND/1/ 
DATA  MNAV_VAL_IND/1/ 
DATA  RTT_REQUEST_IND/0/ 
DATA  NVS/24/ 


DATA  OMEGAO/30. 0,30. 0,30. 0,30.0, 

1  90.0,90.0,90.0,90.0, 

2  150.0,150.0,150.0,150.0, 

3  210.0,210.0,210.0,210.0, 

4  270.0,270.0,270.0,270.0, 

5  330.0,330.0,330.0,330.0/ 

DATA  ETAO/137. 0,257. 0,17. 0,57.0, 

1  177.0,297.0,57.0,97.0, 

2  217.0,337.0,97.0,137.0, 

3  257.0,17.0,137.0,177.0, 

4  297.0,57.0,177.0,217.0, 

5  337.0,97.0,217.0,257.0/ 

C  RF_OOTPUT_DATA,  DATA_STATUS_MSG,  RP_HEALTH_STATUS_MSG 

C* ******************************************************************* 

C 

C  CONVERT  ALL  SATELLITE  ANGULAR  VARIABLES  FROM  DEGREES  TO  RADIANS 

C 

C* ******************************************************************* 


OPEN (UNIT  =  41, 
OPEN (UNIT  =  42, 
OPEN (UNIT  =  44, 


OPEN (UNIT  =  99, 


FILE 

FILE 

FILE 

FILE 


'DXYZtrue.txt' ) 
’TIME.TXT’ ) 
•VAL.TXT' ) 

•CXS  HA  ECEF.TXT') 
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^  OPEN  (UNIT 
■  OPEN  (UNIT 
^  OPEN  (UNIT 
C  OPEN (UNIT 
OPEN (UNIT 
C  OPEN (UNIT 
C  OPEN (UNIT 
C  OPEN (UNIT 

WRITE (42, 
WRITE (42, 


= 

61, 

FILE 

= 

= 

71, 

FILE 

= 

= 

63, 

FILE 

= 

= 

73, 

FILE 

= 

= 

65, 

FILE 

= 

= 

75, 

FILE 

= 

= 

67, 

FILE 

= 

= 

77, 

FILE 

= 

*) 

TC 

*)  RF_STATE 


•EX.DAT' ) 
'EXCOV.DAT' ) 
'EY. DAT') 
'EYCOV.DAT' ) 
'EZ.DAT' ) 
'EZCOV.DAT' ) 
'BC.DAT' ) 
'BCCOV.DAT' ) 


IF  (TC.LT.0.01)  THEN 
RF_STATE  =  2 
ENDIF 


C 

C  VERSION  1.0  VARIABLE  DECLARATIONS 

C 


MNAVTOV  =  TC 
MLAT  =  ELAT(l) 

MLON  =  ELON(l) 

MALT  =  EALT(l) 

MNVEL  =  ELATR(l) 
k  MEVEL  =  ELONR(l) 
f  MALTR  =  EALTR(l) 

TMNAVTOV  =  TC 
TMLAT  =  TLAT(l) 

TMLON  =  TLON(l) 

TMALT  =  TALT(l) 

TMNVEL  =  TLATR(l) 

TMEVEL  =  TLONR(l) 

TMALTR  =  TALTR(l) 

SNAVTOV  =  TC 
SLAT  =  ELAT (2) 

SLON  =  ELON(2) 

SALT  =  EALT(2) 

SNVEL  =  ELATR(2) 

SEVEL  =  ELONR(2) 

SALTR  =  EALTR(2) 

TSNAVTOV  =  TC 
TSLAT  =  TLAT(2) 

TSLON  =  TLON(2) 

TSALT  =  TALT(2) 

TSNVEL  =  TLATR(2) 

TSEVEL  =  TLONR(2) 

TSALTR  =  TALTR(2) 

BCTRUE  =  CBIAS(2) 

FCTRUE  =  FDRIFT(2) 

C  WRITE (44,  *)  MNAVTOV,  SNAVTOV,  SLAT,  MLON 


REFINEMENT  FILTER  REPRESENTED  AS  A  FINITE  STATE  MACHINE  WITH  7  STATES. 
DEPENDING  ON  THE  STATE,  THE  CORRESPONDING  ACTIONS  ARE  PERFORMED 


C 

C 
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2*  It -k  * -kit 


SELECT  CASE  (RF_STATE) 

c******************************************************************** 

C 

C  CASE  OF  STATE  0:  STARTUP  STATE,  RF  RESET 

C 

C************************ ******************************* ************* 


CASE  (0) 

C  CALL  HOST_INT_PROC  ( ) 

IF  (RF__OPR_SW.EQ.O)  THEN 
RSI  =  0 
RF  STATE  =  0 


1 

2 

3 


C 


ELSE 

CALL  OCP_INT_PROC  (CSCI_VERS_IND,  MS_IND,  MNAVTOV,  MLAT,  MNVEL,  MLON, 

MEVEL,  MALT,  MALTR,  TMNAVTOV,  TMLAT,  TMNVEL,  TMLON,  TMEVEL,  TMALT,  TMALTR, 
SNAVTOV,  SLAT,  SNVEL,  SLON,  SEVEL,  SALT,  SALTR,  TSNAVTOV,  TSLAT,  TSNVEL, 
TSLON,  TSEVEL,  TSALT,  TSALTR,  BCTRUE,  FCTRUE) 

IF  (SNAV_VAL_IND.EQ.O)  THEN 
RSI  =  1 
RF_STATE  =  0 

ELSEIF  (GPS_HEALTH_IND.EQ.O)  THEN 
RSI  =  3 
RF_STATE  =  0 

ELSEIF  (MS_IND.EQ. 1)  THEN 
RSI  =  8 
RF_STATE  =  1 
CALL  BUILD_MASTER_MSG ( ) 

ELSEIF  (MNAV_VAL_IND . EQ . 0 )  THEN 
RSI  =  2 
RF  STATE  =  0 


ELSE 

RSI  =  4 
RF_STATE  =  2 

CALL  RF_SOURCE_DATA_PROC(CSCI_VERS_IND,  NVS,  RF_S TATE, MNAVTOV, MLAT, MLATR, 

1  MLON ,  MLONR ,  MALT ,  MALTR ,  TMNAVTOV ,  TMLAT ,  TMLATR ,  TMLON ,  TMLONR ,  TMALT ,  TMALTR ,  MS  AT 

2  MPRR,  MGPSTOV, MVIS ,  SNAVTOV,  SLAT,  SLATR,  SLON,  SLONR,  SALT,  SALTR,  TSNAVTOV,  TSLAT, 

3  TSLATR,  TSLON,  TSLONR,  TSALT ,  TSALTR ,  SSAT,  SPRR,  SGPSTOV,  SVIS,  INVERS,  EPHEM, HA,  XA 

4  SCOUNT,  YA,  YAEXP,  TC,  SATVIS,  DXTRUE,  DYTRUE,  DZTRUE,  BCTRUE,  FCTRUE, 

5  OMEGAO , ETAO , IOTA) 

CALL  RF_KALMAN_PROC(PA,  PHIA,  RA,  QA,  HA,  SCOUNT,  YA,  YAEXP,  TC,  TOLD, 

1  DXTRUE,  DYTRUE,  DZTRUE,  BCTRUE,  FCTRUE,  XA) 


ENDIF 

ENDIF 


C  CALL  GENERATE  RF_HEALTH_STATUS_MSG  ( ) 


CASE  OF  STATE  1:  MASTER  DESIGNATION 


o  o  o 
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CASE  (1) 

jC  CALL  HOST_INT_PROC ( ) 

P  IF  (RF_OPR_SW.EQ.O)  THEN 

RSI  =  0 
RF_STATE  =  0 

ELSE 

CALL  OCP_INT_PROC  (CSCI_VERS_IND,  MS_IND,  MNAVTOV,  MLAT,  MNVEL,  MLON, 

1  MEVEL,  MALT,  MALTR,  TMNAVTOV,  TMLAT,  TMNVEL,  TMLON,  TMEVEL,  TMALT,  TMALTR, 

2  SNAVTOV,  SLAT,  SNVEL,  SLON,  SEVEL,  SALT,  SALTR,  TSNAVTOV,  TSLAT,  TSNVEL, 

3  TSLON,  TSEVEL,  TSALT,  TSALTR,  BCTRUE,  FCTRUE) 

IF  (SNAV_VAL_IND.EQ.O)  THEN 
RSI  =  1 
RF_STATE  =  0 

ELSEIF  (GPS_HEALTH_IND.EQ.O)  THEN 
RSI  =  3 
RF_STATE  =  0 

ELSE 

C  CALL  BUILD_MASTER_MSG ( ) 

ENDIF 

ENDIF 

C  CALL  GENERATE  RF  HEALTH_STATUS_MSG ( ) 


C******************************** ******* ***************************** 

H  CASE  OF  STATE  2:  SLAVE  DESIGNATION,  INITIALIZATION 

C 

C************************* **************************** *************** 

CASE  (2) 

IOTA  =  lOTA/RAD 
ANGLIM  =  ANGLIM/RAD 

WRITE (42,  * )  RF_STATE 

DO  100  I  =  1,24 

OMEGAO(I)  =  OMEGAO(I)/RAD 
ETAO(I)  =  ETA0(I)/RAD 

100  CONTINUE 

C********************************* ******* **************************** 

COMPUTE  AUXILIARY  FILTER  TRANSITION  MATRIX  PHIA(8,8) 

C************************ ******************************************** 

DO  10  I  =  1,8 
DO  10  J  =  1,8 

PHIA(I,J)  =  0.0 
10  CONTINUE 

DO  I  =  1,8 

^  PHIA(I,I)  =  1.0 

■  END  DO 


PHIA(1,2)  =  0.25 
PHIA(3,2)  =  0.25 


n  n 
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PHIA(5,6)  =0.25 
^  PHIA(7,8)  =  0.25 

£******************************************************************** 

C 

C  INITIALIZE  AUXILIARY  FILTER  STATES , COVARIANCE , RATE  LIMITING 

C  AND  OBSERVATION  MATRICES 

C 

C**************************** ************* *************************** 


DO  I  =  1,8 

XA(I)  =  0.0 
END  DO 

DO  15  I  =  1,8 
DO  15  J  =  1,8 
PA(I,J)  =  0.0 
QA(I,J)  =  0.0 
15  CONTINUE 

DO  I  =  1,5,2 

PA(I,I)  =  POSX 
END  DO 

DO  I  =  2,6,2 

PA(I,I)  =  (0.0)**2 
C  PA(I,I)  =  (1.0)**2 

END  DO 

PA(7,7)  =  BCX 
PA(8,8)  =  PCX 

^  DO  I  =  1,5,2 

QA(I,I)  =  PNX 
END  DO 


DO  I  =  2,6,2 

QA(I,I)  =  (0.0)**2 
C  QA(I,I)  =  {0.2)**2 

END  DO 


QA(7,7)  =  BCPNX 
QA(8,8)  =  FCPNX 


DO  20  I  =  1,12 
DO  20  J  =  1,12 
RA(I,J)  =  0.0 
20  CONTINUE 

RA(1,1)  =  RNX 
RA(2,2)  =  RNX2 


DO  I  =  3,12 

RA(I,I)  =  RNX3 
END  DO 


TOLD  =  TC 


RF  STATE 


3 
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RF  INITIALIZATION 


CALL  HOST_INT_PROC ( ) 

IF  (RF_OPR_SW.EQ.O)  THEN 
RSI  =  0 
RF  STATE  =  0 


ELSE 

CALL  OCP_INT_PROC  (CSCI_VERS_IND,  MS_IND,  MNAVTOV,  MLAT,  MNVEL,  MLON, 

1  MEVEL,  MALT,  MALTR,  TMNAVTOV,  TMLAT,  TMNVEL,  TMLON,  TMEVEL,  TMALT,  TMALTR, 

2  SNAVTOV,  SLAT,  SNVEL,  SLON,  SEVEL,  SALT,  SALTR,  TSNAVTOV,  TSLAT,  TSNVEL, 

3  TSLON,  TSEVEL,  TSALT,  TSALTR,  BCTRUE,  FCTRUE) 


IF  (SNAV_VAL_IND.EQ.O)  THEN 
RSI  =  1 
RF_STATE  =  0 

ELSE IF  (GPS_HEALTH_IND.EQ.O)  THEN 
RSI  =  3 
RF_STATE  =  0 

ELSEIF  (MNAV_VAL_IND . EQ . 0 )  THEN 
RSI  =  2 
RF_STATE  =  0 

ELSE  IF  (GPS_STRENGTH . EQ . 0 ) THEN 
RSI  =  6 
RF  STATE  =  5 


1 

2 

3 

4 

5 


1 


ELSE 

CALL  RF_SOURCE_DATA_PROC(CSCI_VERS_IND,  NVS, RF_S TATE, MNAVTOV, MLAT, MLATR, 

MLON , MLONR , MALT , MALTR , TMNAVTOV , TMLAT , TMLATR , TMLON , TMLONR , TMALT , TMALTR , MSAT , 
MPRR , MGPSTOV, MVIS , SNAVTOV, SLAT , SLATR , SLON , SLONR , SALT , SALTR , TSNAVTOV , TSLAT , 
TSLATR, TSLON, TSLONR, TSALT , TSALTR , SSAT, SPRR, SGPSTOV, SVIS , INVERS , EPHEM, HA, XA, 
SCOUNT,  YA,  YAEXP,  TC,  SATVIS,  DXTRUE,  DYTRUE,  DZTRUE,  BCTRUE,  FCTRUE, 
OMEGAO , ETAO , IOTA) 

CALL  RF_KALMAN_PROC(PA,  PHIA,  RA,  QA,  HA,  SCOUNT,  YA,  YAEXP,  TC,  TOLD, 

DXTRUE,  DYTRUE,  DZTRUE,  BCTRUE,  FCTRUE,  XA) 


ENDIF 

ENDIF 

C  CALL  GENERATE  RF_HEALTH_STATUS_MSG ( ) 


C*********************** ********************************************* 

C 

C  CASE  OF  STATE  3:  SLAVE  DESIGNATION,  GPS  PR,  NOT  STEADY  STATE 

C 

C******************************************************* ************* 


CASE  (3) 

WRITE (42,  *)  RF_STATE,  "a" 

C  CALL  HOST_INT_PROC ( ) 

IF  (RF_OPR_SW.EQ.O)  THEN 
RSI  =  0 
RF  STATE  =  0 


ELSE 

CALL  OCP_INT_PROC  (CSCI_VERS_IND,  MS_IND,  MNAVTOV,  MLAT,  MNVEL,  MLON, 

MEVEL,  MALT,  MALTR,  TMNAVTOV,  TMLAT,  TMNVEL,  TMLON,  TMEVEL,  TMALT,  TMALTR, 
SNAVTOV,  SLAT,  SNVEL,  SLON,  SEVEL,  SALT,  SALTR,  TSNAVTOV,  TSLAT,  TSNVEL, 
TSLON,  TSEVEL,  TSALT,  TSALTR,  BCTRUE,  FCTRUE) 
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WRITE  (44  ,*)  MLATR,  MLONR,  MALTR 
WRITE  (44,  *)MNVEL,MEVEL,SALTR 


IF  (SNAV_VAL_IND.EQ.O)  THEN 
RSI  =  1 
RF_STATE  =  0 

ELSEIF  (GPS_HEALTH_IND.EQ.O)  THEN 
RSI  =  3 
RF_STATE  =  0 

ELSEIF  (MNAV_VAL_IND.EQ.O)  THEN 
RSI  =  2 
RF_STATE  =  0 

ELSEIF  (GPS_STRENGTH.EQ.O)  THEN 
RSI  =  6 
RF  STATE  =  5 


1 

2 

3 

4 

5 


1 


ELSE 

CALL  RF_SOURCE__DATA_PROC  ( CSC I_VERS_IND ,  NVS ,  RF_STATE ,  MNAVTOV ,  MLAT ,  MLATR , 

MLON ,  MLONR ,  MALT ,  MALTR ,  TMNAVTOV ,  TMLAT ,  TMLATR ,  TMLON ,  TMLONR ,  TMALT ,  TMALTR ,  MSAT , 
MPRR ,  MGPSTOV ,  MVI S ,  SNAVTOV ,  SLAT ,  SLATR ,  SLON ,  SLONR ,  SALT ,  SALTR ,  TSNAVTOV ,  TSLAT , 
TSLATR,  TSLON,  TSLONR,  TS ALT ,  TS ALTR ,  SSAT,  SPRR,  SGPSTOV,  SVIS ,  INVERS,  EPHEM,  HA, XA, 
SCOUNT,  YA,  YAEXP,  TC,  SATVIS,  DXTRUE,  DYTRUE,  DZTRUE,  BCTRUE,  FCTRUE, 
OMEGAO , ETAO , IOTA) 

CALL  RF_KALMAN__PROC(PA,  PHIA,  RA,  QA,  HA,  SCOUNT,  YA,  YAEXP,  TC,  TOLD, 

DXTRUE,  DYTRUE,  DZTRUE,  BCTRXJE,  FCTRUE,  XA) 

IF  (SS.EQ.l)  THEN 
RSI  =  5 
RF_STATE  =  4 

ENDIF 

ENDIF 


ENDIF 

C  CALL  GENERATE  RF_HEALTH_STATUS_MSG ( ) 


(^* ******************************************************************* 
C 

C  CASE  OF  STATE  4:  SLAVE  DESIGNATION,  GPS  PR,  STEADY  STATE 

C 

c************** ****************************************************** 


CASE  (4) 

CALL  HOST_INT_PROC  ( ) 

IF  (RF_OPR_SW.EQ.O)  THEN 
RSI  =  0 
RF_STATE  =  0 
WRITE (42,  *)  RF_STATE 
ELSE 

CALL  OCP_INT_PROC  (CSCI_VERS_IND,  MS_IND,  MNAVTOV,  MLAT,  MNVEL,  MLON, 

MEVEL,  MALT,  MALTR,  TMNAVTOV,  TMLAT,  TMNVEL,  TMLON,  TMEVEL,  TMALT,  TMALTR, 
SNAVTOV,  SLAT,  SNVEL,  SLON,  SEVEL,  SALT,  SALTR,  TSNAVTOV,  TSLAT,  TSNVEL, 
TSLON,  TSEVEL,  TSALT,  TSALTR,  BCTRUE,  FCTRUE) 

IF  (SNAV_VAL_IND.EQ.O)  THEN 
RSI  =  1 
RF  STATE  =  0 


to  M 
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ELSEIF  (GPS_HEALTH_IND.EQ.O) 
RSI  =  3 
RF  STATE  =  0 


THEN 


ELSEIF  (MNAV_VAL_IND . EQ . 0 )  THEN 
RSI  =  2 
RF  STATE  =  0 


ELSEIF  (GPS_STRENGTH.EQ.O)  THEN 
RSI  =  6 
RF  STATE  =  5 


ELSE 

CALL  RF_SOURCE_DATA_PROC(CSCI_VERS_IND,  NVS, RF_STATE, MNAVTOV,MLAT,MLATR, 

1  MLON , MLONR , MALT , MALTR , TMNAVTOV , TMLAT , TMLATR , TMLON , TMLONR , TMALT , TMALTR , MS AT , 

2  MPRR, MGPSTOV, MVIS , SNAVTOV, SLAT, SLATR, SLON, SLONR, SALT, SALTR, TSNAVTOV, TSLAT, 

3  TSLATR, TSLON, TSLONR,  TSALT, TSALTR, SSAT, SPRR, SGPSTOV, SVIS , INVERS , EPHEM, HA, XA, 

4  SCOUNT,  YA,  YAEXP,  TC,  SATVIS,  DXTRUE,  DYTRUE,  DZTRUE,  BCTRUE,  FCTRUE, 

5  OMEGAO , ETAO , IOTA) 


CALL  RF_KALMAN_PROC(PA,  PHIA,  RA,  QA,  HA,  SCOUNT,  YA,  YAEXP,  TC,  TOLD, 
1  DXTRUE,  DYTRUE,  DZTRUE,  BCTRUE,  FCTRUE,  XA) 

ENDIF 

ENDIF 

C  CALL  GENERATE_RFHEALTH_STATUS_MSG ( ) 


C 

C  CASE  OF  STATE  5:  SLAVE  DESIGNATION,  RTT&PPLI,  NOT  STEADY  STATE 

C 

C******************************************************************** 


CASE  (5) 

C  CALL  HOST_INT_PROC ( ) 

IF  (RF_OPR__SW.EQ.O)  THEN 
RSI  =  0 
RF  STATE  =  0 


C 


3 


ELSE 

CALL  RTT__REQUEST  ( ) 

CALL  OCP_INT__PROC  (CSCI__VERS_IND,  MS_IND,  MNAVTOV,  MLAT,  MNVEL,  MLON, 

MEVEL,  MALT,  MALTR,  TMNAVTOV,  TMLAT,  TMNVEL,  TMLON,  TMEVEL,  TMALT,  TMALTR, 
SNAVTOV,  SLAT,  SNVEL,  SLON,  SEVEL,  SALT,  SALTR,  TSNAVTOV,  TSLAT,  TSNVEL, 
TSLON,  TSEVEL,  TSALT,  TSALTR,  BCTRUE,  FCTRUE) 

IF  (SNAV__VAL_IND.EQ.O)  THEN 
RSI  =  1 
RF__STATE  =  0 

ELSEIF  (MNAV_VAL_IND . EQ . 0 )  THEN 
RSI  =  2 
RF__STATE  =  0 

ELSEIF  (GPS_STRENGTH.EQ.l)  THEN 
RSI  =  4 
RF  STATE  =  2 


ELSE 
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CALL  RF_SOURCE_DATA_PROC(CSCI_VERS__IND,  NVS,  RF_STATE,  MNAVTOV,  MLAT, MLATR, 

1  MLON ,  MLONR ,  MALT ,  MALTR ,  TMNAVTO  V ,  TMLAT ,  TMLATR ,  TMLON ,  TMLONR ,  TMALT ,  TMALTR ,  MS  AT , 

2  MPRR,MGPSTOV,MVIS,  SNAVTOV,  SLAT,  SLATR,  SLON,  SLONR,  SALT,  SALTR,  TSNAVTOV,  TSLAT, 

3  TSLATR,  TSLON,  TSLONR,  TS ALT ,  TS ALTR ,  SSAT,  SPRR,  SGPSTOV,  SVIS ,  INVERS,  EPHEM, HA, XA, 

4  SCOUNT,  YA,  YAEXP,  TC,  SATVIS,  DXTRUE,  DYTRUE,  DZTRUE,  BCTRUE,  FCTRUE, 

5  OMEGAO , ETAO , IOTA) 


CALL  RF_KALMAN_PROC(PA,  PHIA,  RA,  QA,  HA,  SCOUNT,  YA,  YAEXP,  TC,  TOLD, 
1  DXTRUE,  DYTRUE,  DZTRUE,  BCTRUE,  FCTRUE,  XA) 

C  IF  (SS.EQ.l)  THEN 

C  RSI  =  7 

C  RF_STATE  =  6 

C  ENDIF 

ENDIF 

ENDIF 

C  CALL  GENERATE  RF  HEALTH_STATUS_MSG  ( ) 


C*** ******************** ************* ******* ************************* 

C 

C  CASE  OF  STATE  6:  SLAVE  DESIGNATION,  RTT&PPLI,  STEADY  STATE 

C 

C********************* **************** ******************************* 


CASE  (6) 

CALL  HOST_INT_PROC ( ) 

I F  ( RF_OPR_SW . EQ . 0 )  THEN 
RSI  =  0 
RF  STATE  =  0 


ELSE 

C  CALL  RTT_REQUEST ( ) 

CALL  OCP_INT_PROC  (CSCI_VERS_IND,  MS_IND,  MNAVTOV,  MLAT,  MNVEL,  MLON, 

1  MEVEL,  MALT,  MALTR,  TMNAVTOV,  TMLAT,  TMNVEL,  TMLON,  TMEVEL,  TMALT,  TMALTR, 

2  SNAVTOV,  SLAT,  SNVEL,  SLON,  SEVEL,  SALT,  SALTR,  TSNAVTOV,  TSLAT,  TSNVEL, 

3  TSLON,  TSEVEL,  TSALT,  TSALTR,  BCTRUE,  FCTRUE) 

IF  (SNAV_VAL_IND.EQ.O)  THEN 
RSI  =  1 
RF_STATE  =  0 

ELSEIF  (MNAV_VAL_IND.EQ.O)  THEN 
RSI  =  2 
RF_STATE  =  0 

ELSEIF  (GPS_STRENGTH.EQ.l)  THEN 
RSI  =  4 
RF_STATE  =  2 

ELSE 

CALL  RF_SOURCE_DATA_PROC{CSCI_VERS_IND,  NVS,  RF_S TATE,  MNAVTOV, MLAT, MLATR, 

1  MLON ,  MLONR ,  MALT ,  MALTR ,  TMNAVTOV ,  TMLAT ,  TMLATR ,  TMLON ,  TMLONR ,  TMALT ,  TMALTR ,  MS  AT , 

2  MPRR, MGPSTOV,  MVIS ,  SNAVTOV,  SLAT,  SLATR,  SLON,  SLONR,  SALT,  SALTR,  TSNAVTOV,  TSLAT, 

3  TSLATR,  TSLON,  TSLONR,  TSALT,  TSALTR,  SSAT,  SPRR,  SGPSTOV,  SVIS,  INVERS,  EPHEM, HA,  XA, 

m  4  SCOUNT,  YA,  YAEXP,  TC,  SATVIS,  DXTRUE,  DYTRUE,  DZTRUE,  BCTRUE,  FCTRUE, 

^  5  OMEGAO , ETAO , IOTA) 


CALL  RF  KALMAN  PROC  (PA,  PHIA,  RA,  QA,  HA,  SCOUNT,  YA,  YAEXP,  TC,  TOLD, 
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1  DXTRUE,  DYTRUE,  DZTRUE,  BCTRUE,  FCTRUE,  XA) 

ENDIF 

ENDIF 

C  CALL  GENERATE_RF_HEALTH_STATUS_MSG  ( ) 

END  SELECT 


RETURN 

END 

C####################################################################### 

C  SUBROUTINE  GENERATE_RF_HEALTH_MSG ( ) 


C  RETURN 
C  END 


I####################################################################### 

C  SUBROUTINE  RTT_REQUEST ( ) 


C  RETURN 
C  END 


C== 


SUBROUTINE  DTMAML (  A,  B,  C,  IRA,  ICA,  IRB,  ICB,  IFTRA,  IFTRB  ) 

C  This  subroutine  multiplies  two  double  precision  matrices  (or  their  transposes)  of  arbitrary  size. 
C  Matrices  A,B,C  must  be  physically  distinct. 


C  I  History 

C  1  Ver  1.00  JUL-01-1993  JEC  Initial  Release 


C 


!  Input  argument  declarations. 


REAL*8 
INTEGER* 4 
INTEGER*4 
INTEGER* 4 


A(*),  B(*) 

IRA,  ICA,  IRB,  ICB 

IFTRA 

IFTRB 


!  Output  argument  declarations. 
REAL*8  C(*) 

!  Local  declarations . 

REAL* 8  CSUM 

INTEGER*4  NRA,  NCA,  NRB,  NCB 

INTEGER*4  NA,  NB,  NC 
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INTEGER*  4 
INTEGER* 4 
INTEGER* 4 

$ 


NXA,  NXB,  NYB 
I,  J,  K 

IOP,IAA,  IA,KAA,KAO,  JBB,  JBO,KBB,KBO,  JCC,  JCO,KC,  JB,KA, 
KB,  JC 


I  Get  the  location  (address)  of  C  and  see  if  its  the  same  as  that  of  A  or  B. 
IF  (  %LOC(C)  .EQ.  %LOC(A)  .OR.  %LOC(C)  .EQ.  %LOC(B)  )  THEN 
WRITE (  *,  ' ’  Error  in  MAT_MULT  -  C  is  A  or  B’ ') '  ) 

RETURN 
END  IF 


!  Determine  option. 

NRA  =  IRA 

NCA  =  ICA 

NRB  =  IRB 

NCB  =  ICB 

lOP  =  IFTRA  +  IFTRB  +  IFTRB  +  1 

GO  TO  {  2,  5,  8,  11) ,  lOP 

I  Conventional  multiply  A  *  B. 
CONTINUE 


lAA 

= 

1 

lA 

= 

0 

KAA 

NRA 

KAO 

= 

-NRA 

JBB 

= 

NCA 

JBO 

= 

-NCA 

KBB 

= 

1 

KBO 

= 

0 

JCC 

= 

NRA 

JCO 

= 

-NRA 

NXA 

NRA 

NXB 

= 

NCB 

NYB 

= 

NCA 

GO 

TO  15 

1  Transpose  A  only. 
CONTINUE 

lAA  =  NRA 
lA  =  -NRA 
KAA  =  1 
KAO  =  0 
JBB  =  NRB 
JBO  =  -NRB 
KBB  =  1 
KBO  =  0 
JCC  =  NCA 
JCO  =  -NCA 
NXA  =  NCA 
NXB  =  NCB 
NYB  =  NRA 
GO  TO  15 

!  Transpose  B  only. 
CONTINUE 

lAA  =  1 
lA  =  0 
KAA  =  NRA 
KAO  =  -NRA 
JBB  =  1 
JBO  =  0 
KBB  =  NRB 
KBO  =  -NRB 
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JCC  =  NRA 
JCO  =  -NRA 
NXA  =  NRA 
NXB  =  NRB 
NYB  =  NCA 
GO  TO  15 


C  i  Transpose  A  and  B. 

11  CONTINUE 

lAA  =  NRA 
lA  =  -NRA 
KAA  =  1 
KAO  =  0 
JBB  =  1 
JBO  =  0 
KBB  =  NRB 
KBO  =  -NRB 
JCC  =  NCA 
JCO  =  -NCA 
NXA  =  NCA 
NXB  =  NRB 
NYB  =  NRA 

C  1  Multiply  the  matrices. 

15  CONTINUE 


DO  I  =  1,  NXA 
lA  =  lA  +  lAA 
JC  =  JCO 
JB  =  JBO 
DO  J  =  1,  NXB 
JC  =  JC  +  JCC 
JB  =  JB  +  JBB 
KA  =  KAO 
KB  =  KBO 
CSUM  =  0. 

DO  K  =  1,  NYB 

KA  =  KA  +  KAA 
KB  =  KB  +  KBB 
NA  =  KA  +  lA 
NB  =  KB  +  JB 

CSUM  =  CSUM  +  A(NA)  *  B (NB) 
END  DO 
NC  =  JC  +  I 
C(NC)  =  CSUM 
END  DO 
END  DO 


RETURN 

END 


C= 


c 

c 

c 

c 


c 


SUBROUTINE  DMINVl  (A,  N,  D) 

1  This  routine  inverts  a  matrix,  in  place.  This  is  an  IBM  subroutine,  I  beleive.  I  changed 
!  the  arguments,  slightly,  reformated  code  for  clarity,  and  declared  all  variables.  Since  the 
!  code  was  probably  written  in  fortran  66  or  fortran  IV  one  has  to  be  careful  with  do  loops 
!  if  compiling  under  fortran  77.  Everything  looks  and  tested  ok. 

1  History: 

I  Ver  1.01  OCT- 13 -19 94  JEC  Brought  over  to  RNS,  reformated  comments  slightly. 

!  Ver  1.00  FEB-02-1990  JEC  Initial  creation. 

1  Limitations : 
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I  Argument  declarations. 

REAL*8  A(*) 

REAL* 8  D 

INTEGER* 4  N 

I  Local  declarations . 

REAL*8  BIGA,  HOLD 

INTEGER*4  L(20) ,M{20) , NK, KK, K, J, KJ, IJ, IZ, I, KI, JI, JP, JK, JR, JQ, IK 

LOGICAL  FLAG 

1  Search  for  largest  element. 

FLAG  =  .FALSE. 

D  =  1.0 

NK  =  -N 

DO  80  K  =  1,  N 

NK  =  NK  +  N 
L(K)  =  K 
M(K)  =  K 
KK  =  NK  +  K 
BIGA  =  A(KK) 

DO  20  J  =  K,  N 

IZ  =  N  *  (J-1) 

DO  20  I  =  K,  N 
IJ  =  IZ  +  I 

10  IF  (  ABS(BIGA)  -  ABS{A(IJ))  )  15,20,20 

15  BIGA  =  A(IJ) 

L(K)  =  I 
M(K)  =  J 
20  CONTINUE 

I  Interchange  rows . 

J  =  L(K) 

IF  (  J-K  )  35,35,25 
25  KI  =  K  -  N 

DO  I  =  1,  N 

KI  =  KI  +  N 
HOLD  =  -A(KI) 

JI  =  KI  -  K  +  J 
A(KI)  =  A(JI) 

A(JI)  =  HOLD 
END  DO 

I  Interchange  columns 
35  I  =  M(K) 

IF  {  I  -  K  )  45,45,38 

38  JP  =  N  *  (I-l) 

DO  J  =  1,  N 

JK  =  NK  +  J 
JI  ^  JP  +  J 
HOLD  =  -'A(JK) 

A(JK)  =  A{JI) 

A(JI)  =  HOLD 
END  DO 

!  Divide  column  by  minus  pivot  (value  of  pivot  element  is  contained  in  biga) 

45  IF(BIGA)  48,46,48 

46  FLAG  =  .TRUE. 

WRITE  (6,200) 

200  FORMAT (/lx,  "THE  MATRIX  IS  SINGULAR”) 
write (42, *) time,  "singular” 

RETURN 

DO  55  I  =  1,  N 
IF  (  I  -  K  )  50,55,50 


48 


o  n 
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50  IK  =  NK  +  I 

k  A(IK)  =  A(IK)  /  (-BIGA) 

p5  CONTINUE 

C  !  Reduce  matrix 

DO  65  I  =  1,  N 
IK  =  NK  +  I 
IJ  ^  I  -  N 
DO  65  J  =  1,  N 
IJ  =  IJ  +  N 
IF  (  I  -  K  )  60,65,60 
60  IF  (  J  -  K  )  62,65,62 

62  KJ  =  IJ  -  I  +  K 

A(IJ)  =  A(IK)  *  A(KJ)  +  A(IJ) 

65  CONTINUE 

C  1  Divide  row  by  pivot 

KJ  =  K  -  N 
DO  75  J  =  1,  N 
KJ  =  KJ  +  N 
IF  (  J-K  )  70,75,70 
70  A(KJ)  =  A(KJ)  /  BIGA 

75  CONTINUE 

C  !  Product  of  pivots 

D  =  D  *  BIGA 

C  i  Replace  pivot  by  reciprocal 

A(KK)  =  l.ODOO  /  BIGA 

80  CONTINUE 

jC  I  Final  row  and  column  interchange 

P  K  =  N 
100  K  =  K-1 

IF  {  K  )  150,150,105 
105  I  =  L(K) 

IF  (  I-K  )  120,120,108 
108  JQ  =  N  *  (K-1) 

JR  =  N  *  (I-l) 

DO  110  J  =  1,  N 
JK  =  JQ  +  J 
HOLD  =  A(JK) 

JI  =  JR  +  J 
A(JK)  =  -A(JI) 


110 

A(JI)  =HOLD 

120 

J 

=  M(K) 

IF 

(  J-K  ) 

100,100,125 

125 

KI 

=  K  -  N 

DO 

130  I  = 

1,  N 

KI  = 

KI  +  N 

HOLD 

=  A{KI) 

JI  = 

KI  -  K 

+  J 

A(KI) 

=  -A(JI) 

130  A(JI)  =  HOLD 
GO  TO  100 


150  RETURN 
END 


VERSION  NO.  1.0  DATE:  24  FEBRUARY  2003 


o  o 
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PURPOSE:  SYNCHRONIZES  AND  PREPARES  DATA  FOR  KALMAN  PROCESSING.  MASTER  GPS 

DATA  ARE  EXTRACTED  FROM  THE  MASTER  MESSAGE  AND  PAIRED  WITH  OWN  NAV 
SOLUTION. 

INPUTS : 

CSCI_VERS_IND  -  Laboratory/Field  Indicator 
EPHEM(30,23)  -  Satellite  Ephemeris  Data 


MNAV_DATA  (MASTER  NAV  DATA  PACKAGE) 

MNAVTOV  -  Time  of  Validity  of  MASTER  Navigation  solution 

MLAT  -  ESTIMATED  MASTER  Latitude  position  [rad] 

MLATR  -  ESTIMATED  MASTER  Latitude  rate  [rad/s] 

MLON  -  ESTIMATED  MASTER  Longitude  position  [rad] 

MLONR  -  ESTIMATED  MASTER  Longitude  rate  [rad/s] 

malt  -  ESTIMATED  MASTER  Altitude  [m] 

MALTR  “  ESTIMATED  MASTER  Altitude  rate  [m/s] 

TMLAT  ”  TRUE  MASTER  Latitude  position  [rad] 

TMLATR  -  TRUE  MASTER  Latitude  rate  [rad/s] 

TMLON  -  TRUE  MASTER  Longitude  position  [rad] 

TMLONR  -  TRUE  MASTER  Longitude  rate  [rad/s] 

TMALT  -  TRUE  MASTER  Altitude  [m] 

TMALTR  -  TRUE  MASTER  Altitude  rate  [m/s] 

MNAV_VAL_IND  -  MASTER  navigation  validity  indicator 

MGPS_DATA 

MVIS  “  Number  of  satellites  visible  to  MASTER 

MSAT{MVIS)  -  MASTER  Ordered  Satellite  List 

MPRR(MVIS)  -  MASTER  Ordered  measured  code  phase  array 

MGPSTOV  ~  MASTER  predicted  GPS  time  of  validity 

MINVERS{30)  -  Satellite  sorting  index 

SNAV_DATA  (SELF  NAV  DATA  PACKAGE) 

SNAVTOV  “  Time  of  Validity  of  SELF  Navigation  solution 

SLAT  -  ESTIMATED  SELF  Latitude  position  [rad] 

SLATR  -  ESTIMATED  SELF  Latitude  rate  [rad/s] 

SLON  -  ESTIMATED  SELF  Longitude  position  [rad] 

SLONR  ”  ESTIMATED  SELF  Longitude  rate  [rad/s] 

SALT  -  ESTIMATED  SELF  Altitude  [m] 

SALTR  -  ESTIMATED  SELF  Altitude  rate  [m/s] 

TSLAT  -  TRUE  SELF  Latitude  position  [rad] 

TSLATR  -  TRUE  SELF  Latitude  rate  [rad/s] 

TSLON  -  TRUE  SELF  Longitude  position  [rad] 

TSLONR  -  TRUE  SELF  Longitude  rate  [rad/s] 

TSALT  -  TRUE  SELF  Altitude  [m] 

TSALTR  -  TRUE  SELF  Altitude  rate  [m/s] 

BCTRUE  -  TRUE  clock  bias 

FCTRUE  -  TRUE  frequency  drift. 

SNAV_VAL_IND  -  SELF  navigation  validity  indicator 

SGPS__DATA 

SVIS  -  Number  of  satellites  visible  to  SELF 

SSAT{SVIS)  -  SELF  Ordered  Visible  Satellite  List 

SPRR{SVIS)  -  SELF  Ordered  measured  code  phase  array 

SGPSTOV  -  SELF  predicted  GPS  time  of  validity 

SINVERS(30)  ’  Satellite  sorting  index 

OMEGAO(24)  -  Lat  coordinates  of  satellites 

ETA0(24)  -  Lon  coordinates  of  satellites 

IOTA  -  Satellite  Inclination 


OUTPUTS : 
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PA(8,8) 

PHIA(8,8) 
RA(12,12) 

QA(8,8) 

HA{12,8) 

SCOUNT 
YA(  INDEX) 

YAEXP  (INDEX) 

TC 

SATVIS(j) 

ANGLIM 
C  DXTRUE 
C  DYTRUE 
C  DZTRUE 
C  BCTRUE 
C  FCTRUE 
C 

c 

C  STORED  CONSTANTS : 
C 

C  IX 
C  RNGISG 
C  ZEROH 
C 

C  OMEGAE 
C  OMEGAS 
C  RK 
C  RAD 
C  QUANT 
C 
C 


-  Covariance  Matrix 
State  transition  Matrix 
Measurement  Error 

-  Process  Noise 
Observation  matrix 

Final  number  of  paired  satellites  visible  above  ANGLIM 

-  INDEX  =  1,  14  Observation  measurement  vector 

INDEX  =1,  14  Observation  prediction  vector 

Reference  time  at  which  measurements  are  valid  since  GPS  time  of  week  [s] 
j  =  1,  SCOUNT  Ordered  array  of  common  visible  satellites  above 


TRUE  error  composites. 
TRUE  clock  bias 
TRUE  frequency  drift. 


12478  Seed  for  random  number  generator 

21.0  Standard  Dev 

O.ODO  Mean  for  random  number 

7.292115467  E-5  [RAD/S]  Earth's  rotational  rate 
1.45858522  E-4  [RAD/S]  Satellite  orbital  rate 

87051108  [ft]  Radius  of  satellite  orbit 

57 .2957795131  Radians /Degree 

12.5 


C 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


CALLED  BY: 

RF  EXEC  CTRL 


SUBROUTINES : 

COMPARERS AT_IND I CES 
COMPUTE_CIRC_SAT_ECEF 
COMPUTE_ELLIP_SAT_ECEF 
XFORM_NAV_COORDINATES 
COMPUTE_LAB_S  AT_VI  S 
COMPUTE_FIELD_SAT_VIS 
PROCESS_PR_DATA 
GENERATE  KALMAN  OBS  SET 


MODICATION  HISTORY: 

VI. 0  ORIGINAL  VERSION  DATE  RESPONSIBLE 

FOR  VERSION  1.0  4/03/03  JYH 


SUBROUTINE  RF_SOURCE_DATA_PROC  {CSCI_VERS__IND,  NVS,  RF_STATE,MNAVTOV,MLAT,MLATR, 

1  MLON ,  MLONR ,  MALT ,  MALTR ,  TMNAVTOV ,  TMLAT ,  TMLATR ,  TMLON ,  TMLONR ,  TMALT ,  TMALTR ,  MS  AT , 

2  MPRR,  MGPSTOV, MVIS ,  SNAVTOV,  SLAT,  SLATR,  SLON,  SLONR,  SALT,  SALTR,  TSNAVTOV,  TSLAT,  TSLATR, 

3  TSLON,  TSLONR,  TSALT, TSALTR,  SSAT,  SPRR,  SGPSTOV,  SVIS,  INVERS,  EPHEM,  HA,  XA, 

4  SCOUNT,  YA,  YAEXP,  TC,  SATVIS,  DXTRUE,  DYTRUE,  DZTRUE,  BCTRUE,  FCTRUE, 

5  OMEGAO , ETAO , IOTA) 


o  n\ 
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DECLARATION  OF  VARIABLES 


C  COMMON  MVIS,  SVIS,  NVS,  CSCI_VERS_IND,  SCOUNT,  TC 


IMPLICIT  NONE 


INTEGER*4  MVIS,  SVIS,  NVS,  SCOUNT,  RF_STATE,  CSCI_VERS_IND,  MS,  TE 

REAL*8  MSAT(MVIS),  SSAT(SVIS),  MPRR(MVIS),  SPRR(MVIS),  SAT(NVS),  PRRl(NVS),  PRR2 (NVS) 
REAL*8  EPHEM(23,30) ,  INVERS(30),  ECEFXS(30),  ECEFYS(30),  ECEFZS(30) 

REAL*8  OMEGAO(24),  ETA0(24),  IOTA 

REAL*8  TMGPSTOV,  TMNAVTOV,  TMLAT,  TMLATR,  TMLON,  TMLONR,  TMALT,  TMALTR,  TMLLPX, TMLLPY, 

REAL*8  TSGPSTOV,  TSNAVTOV,  TSLAT,  TSLATR,  TSLON,  TSLONR,  TSALT,  TSALTR,  TSLLPX, TSLLPY, 

REAL*8  MGPSTOV,  MNAVTOV,  MLAT,  MLATR,  MLON,  MLONR,  MALT,  MALTR,  MLLPX,  MLLPY,  MLLPZ 

REAL*8  SGPSTOV,  SNAVTOV,  SLAT,  SLATR,  SLON,  SLONR,  SALT,  SALTR,  SLLPX,  SLLPY,  SLLPZ 


TMLLPZ 

TSLLPZ 


REAL*8  MPGPSTM(NVS) ,  SPGPSTM(NVS) 

REAL*8  TLE(3,3) ,XA(8) ,  BCTRUE,  FCTRUE 

REAL*8  ECEFS (3,1),  LLSAT (3,1),  LLSATX (NVS) ,  LLSATY (NVS) ,  LLSATZ (NVS) 

REAL*8  SDIFP(3),  MDIFF(3),  TSDIFF(3),  TMDIFP(3),  VIS (NVS) 

REAL*8  SATVIS(NVS),  EMPR(NVS),  ESPR(NVS),  TMPR(NVS),  TSPR(NVS) , CXS (24) ,  CYS(24),  CZS(24) 


REAL*8  BPR2M,  BBC2M,  TC,  HA(12,8),  YA(12) ,YAEXP (12) ,  DXTRUE,  DYTRUE,  DZTRUE 


REAL* 8  OMEGAE,  OMEGAS,  RK,  RAD 


REAL*8  QUANT,  RANGEM,  RTRAB,  RNGISG,  ZEROH,  RAND,  EHRNGE,  BIASM 


INTEGER*4  IBIAS, IRANGE, INDEX, IX 

DATA  IX/12478/ 

DATA  RNGlSG/2 1.0/ 

DATA  ZEROH/ 0 . ODO / 

DATA  OMEGAE, OMEGAS/ 7 . 292115467E-5 , 1 . 45858522E-4/ 
DATA  RK/87051108./ 

DATA  RAD/57.2957795131/ 

DATA  QUANT/12.5/ 


C* ******************************************************************* 

C 

C  BEGIN 

C 

c******************************************************************** 

OPEN (UNIT  =  41,  FILE  =  'DXYZtrue.txt') 

OPEN (UNIT  =  43,  FILE  =  * DEBUG. TXT’) 


IF  (CSCI_VERS_IND.EQ.l)  THEN 

CALL  COMPUTE  SAT  CIRC  ECEF  (TC,  NVS,  OMEGAO,  ETAO,  IOTA,  ECEFXS,  ECEFYS,  ECEFZS) 


MS  =  1 
TE  =  1 

CALL  XFORM__NAV_COORD  (TMGPSTOV,  TMNAVTOV,  TMLAT,  TMLATR,  TMLON,  TMLONR,  TMALT,  TMALTR, 
TMLLPX,  TMLLPY,  TMLLPZ,  TLE,  MS,  TE) 


1 
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WRITE (99, 912)  MS, TMLLPX, TMLLPY, TMLLPZ 

FORMATdH  ,  'K/TLLP'  ,1X,I1,3  (1X,E12.6)  ) 

MS  =  2 

CALL  XFORM_NAV_COORD(TSGPSTOV,  TSNAVTOV,  TSLAT,  TSLATR,  TSLON,  TSLONR,  TSALT,  TSALTR, 
TSLLPX,  TSLLPY,  TSLLPZ,  TLE,  MS,  TE) 

WRITE(99, 913)  MS , TSLLPX, TSLLPY, TSLLPZ 

FORMATdH  ,  'K/TLLP'  ,  IX, II, 3  dX,E12 .6)  ) 

MS  =  1 
TE  =  2 

CALL  XFORM_NAV_COORD  (MGPSTOV,  MNAVTOV,  MLAT,  MLATR,  MLON,  MLONR,  MALT,  MALTR, 

MLLPX,  MLLPY,  MLLPZ,  TLE,  MS,  TE) 

WRITE (99, 910)  MS, MLLPX, MLLPY, MLLPZ 

FORMATdH  ,  'K/LLP'  , IX, II, 3  dX,E12.6)  ) 

MS  =  2 

CALL  XFORM_NAV_COORD (SGPSTOV,  SNAVTOV,  SLAT,  SLATR,  SLON,  SLONR,  SALT,  SALTR, 

SLLPX,  SLLPY,  SLLPZ,  TLE,  MS,  TE) 

WRITE (99, 911)  MS, SLLPX, SLLPY, SLLPZ 

FORMATdH  .  'K/LLP'  ,  IX,  11,3  (1X,E12 .6)  ) 


CALL  COMPUTE_LAB_SAT_VIS (NVS ,  SAT,  ECEFXS,  ECEFYS,  ECEFZS,  MLLPX,  MLLPY, 

MLLPZ,  SLLPX,  SLLPY,  SLLPZ,  TMLLPX,  TMLLPY,  TMLLPZ,  TSLLPX,  TSLLPY,  TSLLPZ, 
TLE,  XA,  SCOONT,  SATVIS,  EMPR,  ESPR,  TMPR,  TSPR,  CXS,  CYS,  CZS) 


CALL  GENERATE_KALMAN_OBS_SET (  SCOUNT,  EMPR,  ESPR,  TMPR,  TSPR,  SATVIS,  MLLPX, 

MLLPY,  MLLPZ,  SLLPX,  SLLPY,  SLLPZ,  TMLLPX,  TMLLPY,  TMLLPZ,  TSLLPX,  TSLLPY,  TSLLPZ, 

2  BPR2M,  BBC2M,  TC,  RP_STATE,  XA,  HA,  YA,  YAEXP,  DXTRUE,  DYTRUE,  DZTRUE, BCTRUE, CXS, CYS, CZS) 

RETURN 

ELSE 

C . . --- - - - - - 

c 

C  INSERT  CODE  FOR  BUFFERING  OF  MASTER/SELF  DATA  PACKAGES 
C  PAIR  EARLIEST  UNUSED  MASTER/SELF  PACKAGES 
C 

c - 

CALL  COMPARE_SAT_INDICES  (MVIS,  SVIS,  MSAT,  SSAT,  MPRR,  SPRR,  NVS, 

1  SAT,  PRRl,  PRR2) 

CALL  COMPUTE_SAT_ELLIP_ECEF(PRR2,  EPHEM,  NVS,  SAT,  INVERS,  SGPSTOV, 

1  ECEFXS,  ECEFYS,  ECEFZS) 

MS  =  1 

CALL  XFORM_NAV_COORD  (MGPSTOV,  MNAVTOV,  MLAT,  MLATR,  MLON,  MLONR,  MALT,  MALTR, 

1  MLLPX,  MLLPY,  MLLPZ,  TLE,  MS,  TE) 

MS  =  2 

CALL  XFORM_NAV_COORD (SGPSTOV,  SNAVTOV,  SLAT,  SLATR,  SLON,  SLONR,  SALT,  SALTR, 

1  SLLPX,  SLLPY,  SLLPZ,  TLE,  MS,  TE) 

IP  (CSCI_VERS_IND-2)  210,  210,  220 

210  CALL  XFORM_NAV_COORD (TMGPSTOV,  TMNAVTOV,  TMLAT,  TMLATR,  TMLON,  TMLONR,  TMALT,  TMALTR, 

1  TMLLPX,  TMLLPY,  TMLLPZ,  TLE,  MS,  TE) 


1 

913 

1 

910 

1 

911 

1 

2 


MS  =  1 
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CALL  XFORM_NAV_COORD (TSGPSTOV,  TSNAVTOV,  TSLAT,  TSLATR,  TSLON,  TSLONR,  TSALT,  TSALTR, 

^  1  TSLLPX,  TSLLPY,  TSLLPZ,  TLE,  MS,  TE) 

MS  =  2 

C  220  CALL  COMPUTE_SAT_VIS ( ) 

220  CALL  PROCESS_PR_DATA (  SCOUNT,  SATVIS,  NVS,  PRRl,  PRR2,  MGPSTOV,  SGPSTOV,  EMPR,  ESPR  ) 

CALL  GENERATE_KALMAN_OBS_SET (  SCOUNT,  EMPR,  ESPR,  TMPR,  TSPR,  SATVIS,  MLLPX, 

1  MLLPY,  MLLPZ,  SLLPX,  SLLPY,  SLLPZ,  TMLLPX,  TMLLPY,  TMLLPZ,  TSLLPX,  TSLLPY,  TSLLPZ, 

2  BPR2M,  BBC2M,  TC,  RF_STATE,  XA,  HA,  YA,  YAEXP,  DXTRUE,  DYTRUE, DZTRUE, BCTRUE, CXS , CYS, CZS) 

ENDIF 


RETURN 

END 


C####################################################################### 

C  SUBROUTINE  COMPARE_SAT_INDICES  (  MVIS,  SVIS,  MSAT(MVIS),  SSAT(SVIS),  MPRR(MVIS), 
C  SPRR(SVIS),  NVS,SAT{NVS) ,  PRRl (NVS) ,  PRR2 (NVS)  ) 

C 

C  PURPOSE:  COMPARES  ORDERED  SATELLITE  INDICES  AND  ALIGNS  SATELLITES  IN  A  SINGLE 
C  ARRAY  CONTAINING  DATA  FOR  PSEUDORANGE  COMPARISON 

C 
C 

C  INPUTS : 

P  MVIS 
C  SVIS 
C  MSAT(MVIS) 

C  SSAT(SVIS) 

C  MPRR(MVIS) 

C  SPRR(SVIS) 

C 
C 

C  OUTPUTS : 

C  NVS 
C  SAT  (NVS) 

C  PRRl (NVS) 

C  PRR2(NVS) 

C 
C 
C 

C####################################################################### 

SUBROUTINE  COMPARE_SAT_INDICES  (  MVIS,  SVIS,  MSAT,  SSAT,  MPRR,  SPRR,  NVS, 

1  SAT,  PRRl,  PRR2) 

IMPLICIT  NONE 

INTEGER*4  MVIS,  SVIS,  NVS,  I,  J 

REAL*8  MSAT(MVIS),  SSAT (SVIS) ,  MPRR (MVIS ) ,  SPRR(SVIS),  SAT(NVS) 

REAL*8  PRRl (NVS),  PRR2 (NVS) 


-  Number  of  satellites  visible  to  MASTER 

-  Number  of  satellites  visible  to  SELF 

-  Ordered  array  of  MASTER  visible  satellites 

-  Ordered  array  of  SELF  visible  satellites 

-  Ordered  array  of  MASTER  code  phase 
Ordered  array  of  SELF  code  phase 


--  Number  visible  satellites  -  common  to  MASTER  and  SELF 
~  Ordered  array  of  common  visible  satellites 

-  MASTER  array  of  code  phase  for  common  satellites 

-  SELF  array  of  code  phase  for  common  satellites 


NVS  =  0 


DO  100  1=1,  MVIS 

DO  WHILE  ( (MSAT(I) .LE.SSAT(J) )  .AND. 
IF  (MSAT(I) .EQ.SSAT(J) )  THEN 
NVS  =  NVS  +  1 


(J.LE.SVIS) ) 
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SAT{I)  =  MSAT(I) 
PRRld)  =  MPRR(I) 


PRR2  (I) 
J  =  J+1 
ENDIF 
END  DO 


=  SPRR(J) 


100  CONTINUE 


PURPOSE:  PERFORMS  THE  CONVERSION  OF  THE  CIRCULAR  SATELLITE  CONSTELLATION 

INTO  ECEF  COORDINATES  FOR  VERSION  1.0 


RETURN 

END 

C####################################################################### 
C  SUBROUTINE  COMPUTE_SAT_CIRC__ECEF  (SNAVTOV,  NVS,  SAT{NVS), 

C  ECEFXS (K) ,  ECEFYS (K) ,  ECEFZS (K) ) 

C 
C 
C 
C 
C 
C 
C 
C 
C 
C 
C 
C 
C 
C 
C 
C 


INPUTS : 
SGPSTOV 
NVS 

SAT  (NVS) 


OUTPUTS : 
ECEFXS (K) 
ECEFYS (K) 
ECEFZS (K) 


-  GPS 

Number  visible  satellites  common  to  MASTER  and  SELF 
Ordered  array  of  common  visible  satellites 


-  ECEF  x-coordinate  for  satellite  K 

-  ECEF  y-coordinate  for  satellite  K 

-  ECEF  z-coordinate  for  satellite  K 


STORED  CONSTANTS 
OMEGAO (K) 

ETAO(I) 


OMEGAE 

OMEGAS 

RK 

IOTA 


K  =  1,  30  Lat  coordinates  of  satellites 

-  K  =  1,  30  Lon  coordinates  of  satellites 
7.292115467  E-5  [RAD/S]  Earth's  rotational  rate 

1.45858522  E-4  [RAD/S]  Satellite  orbital  rate 

87051108  [meters]  Radius  of  satellite  orbit 

55.0/2*pi  [RAD]  Satellite  Inclination 


C 
C 

c 
c 
c 
c 
c 
c 

C####################################################################### 


SUBROUTINE  GOMPUTE_SAT_CIRC__ECEF  (TC,  NVS,  OMEGAO,  ETAO,  IOTA,  ECEFXS,  ECEFYS, 
IMPLICIT  NONE 
INTEGER*4  NVS,  K 

REAL*8  SGPSTOV,  SAT(NVS),  ECEFXS(30),  ECEFYS{30),  ECEFZS(30) 

REAL*8  ETAK,  OMEGAK,  IOTA,  OMEGAO (24),  ETAO (24),  TC 
REAL* 8  OMEGAE,  OMEGAS,  RK,  XKP,YKP 

C  DATA  IOTA/0. 959931088596585/ 

DATA  OMEGAE, OMEGAS/7. 292115467E-5, 1.45858522E-4/ 

DATA  RK/87051108./ 

C  DATA  RAD/57.2957795131/ 


C 

C 


CIRCULAR  CONSTELLATION  PROPAGATION  ALGORITHM 
******************************************************************* 


ECEFZS) 


C  IOTA  =  lOTA/RAD 
C  SCOUNT  =  0 
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DO  220  K  =  1,  NVS 


C 

C  INCREMENT  ANGLE  VARIABLES  FOR  SATELLITE  I 

C 

C************************************* *********** ****** ************** 


OMEGAK  =  OMEGAO(K)  -  TC  *  OMEGAE 
ETAK  =  ETAO(K)  +  TC  *  OMEGAS 


C 

C  COMPUTE  ECEF  POSITIONS  OF  EACH  SATELLITE 

C 


XKP  =  RK*DCOS(ETAK) 

YKP  =  RK*DSIN(ETAK) 

ECEFXS(K)  =  XKP*DCOS (OMEGAK)  >  YKP *DS IN (OMEGAK) *DCOS (IOTA) 
ECEFYS(K)  =  XKP*DSIN (OMEGAK)  +  YKP*DCOS (OMEGAK) *DCOS ( IOTA) 
ECEFZS(K)  =  YKP*DSIN(IOTA) 

220  CONTINUE 


RETURN 
END 

C####################################################################### 
C  SUBROUTINE  COMPUTE_SAT_ELLIP_ECEF  (PRR2,  EPHEM (23 , 30 ) ,  NVS,  SAT (NVS), 
C  ECEFXS(K),  ECEFYS(K),  ECEFZS (K) ) 

C 

c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 


INVERS(30),  SGPSTOV, 


PURPOSE:  PERFORMS  THE  CONVERSION  OF  THE  ELLIPTICAL  SATELLITE  CONSTELLATION 

INTO  ECEF  COORDINATES  FOR  VERSION  2.0  AND  ABOVE 

INPUTS : 

NVS  -  Number  visible  satellites  common  to  MASTER  and  SELF 

SAT (NVS)  -  Ordered  array  of  common  visible  satellites 

EPHEM (2 3, 30)  -  Satellite  Ephemeris  Data 

INVERS(30)  -  Satellite  sorting  index 

SGPSTOV  -  Predicted  GPS  time 

BLCK  -  Number  of  PR  reports  (?) 

CDPHASE  -  GPS  Code  phase  value  (?) 

ISVNO  “  Satellite  vehicle  number  (?) 


C 

C 

C 

c 

c 

c 

c 

c 

c 

c 

c 

c 


c 

c 


OUTPUTS : 
ECEFXS (L) 
ECEFYS (L) 
ECEFZS (L) 


ECEF  X- coordinate  for  satellite  L 
ECEF  y-coordinate  for  satellite  L 
ECEF  z-coordinate  for  satellite  L 


STORED  CONSTANTS 

OMEGAO(K)  -  K  =  1,  30  Lat  coordinates  of  satellites 

ETAO(I)  -  K  =  1,  30  Lon  coordinates  of  satellites 

OMEGAE  -  7.292115467  E-5  [RAD/S]  Earth's  rotational  rate 

OMEGAS  -  1.45858522  E-4  [RAD/S]  Satellite  orbital  rate 

RK  -  87051108  [meters]  Radius  of  satellite  orbit 

MU  -  3.986008  E14  [m'^3/s'^2]  Earth's  uni  gravitational  param 

F  -  -4.442807633E-10 
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c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


SVNO 

EPHEM (K,l) 

WEEKNO 

= 

EPHEM (K, 2) 

TGD 

= 

EPHEM (K, 3) 

TOC 

= 

EPHEM (K, 4) 

AF2 

= 

EPHEM (K, 5) 

AFl 

EPHEM (K, 6) 

AFO 

= 

EPHEM (K, 7) 

CRS 

= 

EPHEM(K, 8) 

DELN 

= 

EPHEM(K, 9) 

MO 

EPHEM (K, 10) 

CUC 

= 

EPHEM(K, 11) 

ES 

= 

EPHEM (K, 12) 

CUS 

= 

EPHEM (K, 13) 

SAS 

EPHEM (K, 14) 

TOE 

= 

EPHEM (K, 15) 

CIC 

= 

EPHEM (K, 16) 

OMEGAO 

= 

EPHEM (K, 17) 

CIS 

= 

EPHEM (K, 18) 

IOTA 

= 

EPHEM (K, 19) 

CRC 

EPHEM (K, 20) 

W 

= 

EPHEM (K, 21) 

OMEGAD 

= 

EPHEM (K, 22) 

IDOT 

= 

EPHEM (K, 23) 

Satellite  vehicle  number 

Time  of  week  ***  difference  from  toe 


Amplitude  of  sine  harmonic  correction  term  to  orbit  radius  [m] 
mean  motion  difference  [semicircle/s] 

Mean  anomaly  at  reference  time  [smcir] 

Amplitude  of  cos  harmonic  correction  term  to  the  argument  of  latitude  [rad] 
Eccentricity 

Amplitude  of  sine  harmonic  correction  term  to  the  argument  of  latitude  [rad] 
Square  root  of  semi -major  axis  [m^l/2] 

Ephemeris  reference ; time  (from  Epoch) 

Amplitude  of  cos  harmonic  correction  term  to  the  angle  of  inclination  [rad] 
Longitude  of  ascending  node  of  orbit  plane  at  weekly  epoch 

Amplitude  of  sine  harmonic  correction  term  to  the  angle  of  inclination  [rad] 
Inclination  angle  at  reference  time  [semicircle] 

Amplitude  of  cos  harmonic  correction  term  to  the  orbit  radius  [m] 

Argument  of  perigee  [semicircle] 

Rate  of  right  ascension  [semicircle/s] 

Rate  of  inclination  angle  [semicir/s] 


C####################################################################### 


SUBROUTINE  COMPUTE_SAT_ELLIP__ECEF  (PRR2,  EPHEM,  NVS,  SAT,  INVERS,  SGPSTOV, 
1  ECEFXS,  ECEFYS,  ECEFZS) 


INTEGER*  4  NVS ,  ISVNO 

REAL*8  PRR2(NVS),  EPHEM (23 , 30 ) ,  SGPSTOV,  SAT (NVS),  INVERS (30),  BLCK,  CDPHASE 
REAL* 8  ECEFXS (30),  ECEFYS (30),  ECEFZS (30) 


INTEGER* 4  SVNO,  IPGPS 
REAL* 8  CDPHSE,  CR 

REAL*8  FPGPS,  PRSEC,  TC,  TOE,  TK,  DELN,  SAS,  AS,  N,  MU,  MO,  MK 
REAL*8  ES,  EKNEW,  JX,  EKOLD,  E,  DEKTR,  AFO,  AFl,  AF2,  TGD,  TOC,  DELT,  T 
REAL*8  R,  NUM,  DENOM,  W,  PHI,  CUS,  CUC,  CRS,  OMEGAO,  CIS,  CRC,  CIC,  IOTA,  IDOT 

REAL* 8  C2PHI,  S2PHI,  DELPHI,  DELR,  DELI,  OMEGAD,  OER 


DATA  RAD/57.2957795131/ 

DATA  C/2.99792498E8/ 

DATA  RK/87051108./ 

DATA  PI/3.1415926/ 

DATA  OMEGAE, OMEGAS/7. 2 92115467E-5, 1.45858522E-4/ 
DATA  MU/3.986008E14/ 

DATA  F/-4.442807633E-10/ 

DATA  CR/1/ 


C************************** ********************************** ******** 
1^  ELLIPTICAL  CONSTELLATION  PROPAGATION  ALGORITHM 

c******************************************************************** 
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n 


DO  300  L  =  1,  NVS 


C 

C  INCREMENT  ANGLE  VARIABLES  FOR  SATELLITE  I 

C 

C***** ***************************************** ********************** 

CDPHSE  =  PRR2 (L) 

ISVNO  =  SAT(L) 

IPGPS  =  SGPSTOV 

FPGPS  =  SGPSTOV  -  FLOAT (IPGPS) 

PRSEC  =  FPGPS  -  (CDPHSE/CR) 

IF  (PRSEC  <  0.0)  THEN 
PRSEC  =  1.0  +  PRSEC 


PR  =  PRSEC*C 

TC  =  SGPSTOV  -  PR/C 

TOE  =  EPHEMdNVERS  (ISVNO)  ,  15) 

TK  =  TC  -  TOE 

ENDIF 


IF  (TK  >  302400.0)  THEN 
TC  =  TC  -  604800.0 
ENDIF 

IF  (TK  <  302400.0)  THEN 
TC  =  TC  +  604800.0 
ENDIF 


C 


COMPUTE  MEAN  MOTION 
******************************* 


DELN  =  EPHEMdNVERS  (ISVNO)  ,9) 

SAS  =  EPHEMdNVERS  (ISVNO)  ,14) 

AS  =  SAS**2 

N  =  DSQRT(MU/AS**3)  +  DELN 

C************************************** *****************************  * 

c 

C  COMPUTE  MEAN  ANOMALY 

C 

C************************ *************************** ******** ********* 

MO  =  EPHEMdNVERS  (ISVNO)  ,10) 

MK  =  MO  +  N*(TC  -  TOE) 

C* ****** ************************************************************* 

C 

C  SOLVE  FOR  ECCENTRIC  ANOMALY 

C 

C******** **************************************************** ******** 

ES  =  EPHEMdNVERS  (ISVNO)  ,12) 

EKNEW  =  MK 
DO  JX=1,100 

EKOLD  =  EKNEW 

EKNEW  =  MK  +  ES*DS IN  (EKOLD) 

END  DO 
E  =  EKNEW 


******************************************************************** 
COMPUTE  TIME  CORRECTION  TERM 


C 


non 
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DELTR  =  F*ES*SAS*DSIN(E) 

P  AFO  =  EPHEM ( INVERS ( ISVNO) , 7 ) 

AFl  =  EPHEM (INVERS (ISVNO) ,6) 

AF2  =  EPHEM (INVERS (ISVNO) ,5) 

TGD  =  EPHEM ( INVERS ( ISVNO) , 3 ) 

TOC  =  EPHEM (INVERS (ISVNO) ,4) 

DELT  =  AFO  +  AF1*(TC  -  TOC)  +  AF2* (TC  -  TOC)**2  +  DELTR  -  TGD 

T  =  TC  -  DELT 
R  =  AS* (1.0  -  ES*DSIN(E)) 

C**************************** *************************** ************* 

C 

C  COMPUTE  SATELLITE  TRUE  ANOMALY,  NU 

C 

c* ******************************************************************* 
NUM  =  SORT ((1.0  -  ES*ES)*DSIN(E))/(1.0  -  ES*DCOS(E)) 

DENOM  =  (DCOS (E) -ES) / (1 .0-ES*DCOS (E) ) 

NU  =  ATAN2(NUM,  DENOM) 

W  =  EPHEM (INVERS (ISVNO) ,21) 

PHI  =  NU  +  W 


C* ******************************************************************* 

c 

C  COMPUTE  CORRECTION  TERMS  FOR  HARMONICS 

C 

c*********************** ******************************** ************* 
CUS  =  EPHEM (INVERS (ISVNO) ,13) 
cue  =  EPHEM (INVERS (ISVNO) ,11) 

CRS  =  EPHEM( INVERS (ISVNO) , 8) 
k  OMEGAO  =  EPHEM ( INVERS ( I SVNO ) , 1 7 ) 

f  CIS  =  EPHEMdNVERS  (ISVNO)  ,18) 

CRC  =  EPHEM ( INVERS ( ISVNO) ,20) 

CIC  =  EPHEM (INVERS (ISVNO) ,16) 

IOTA  =  EPHEMdNVERS  (ISVNO)  ,  19) 

IDOT  =  EPHEM (INVERS (ISVNO) ,23) 

C2PHI  =  DCOS(2*PHI) 

S2PHI  =  DSIN(2*PHI) 

C**************************** *********************** ***************** 


SECOND  HARMONIC  PERTURBATIONS 

C************************************************** ****************** 


DELPHI  =  CUS*S2PHI  +  CUC*C2PHI 
DELR  =  CRS*S2PHI  +  CRC*C2PHI 
DELI  =  CIS*S2PHI  +  CIC*C2PHI 

PHI  =  PHI  +  DELPHI 
R  =  R  +  DELR 

IOTA  =  IOTA  +  DELI  +  IDOT* (T-TOE) 

OMEGAD  =  EPHEM (INVERS (ISVNO) ,22) 

OER  =  OMEGAO/RAD  +  (OMEGAD/PI) * (T-TOE)  -  OMEGAE*T 


ECEFXS (L) 
ECEFYS (L) 
ECEFZS (L) 


(R*DCOS (OER) *DCOS (PHI) ) - (R*DSIN(OER) *DCOS (IOTA) *DSIN(PHI) ) 
R*DSIN(OER) *DCOS (PHI) +R*DCOS (OER) *DCOS (IOTA) *DSIN (PHI) 
R*DSIN(IOTA) *DSIN(PHI) 


300 


CONTINUE 
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RETURN 

• 

END 

c####################################################################### 

c 

SUBROUTINE  XFORM  NAV  COORD  (NAVTOV,  LAT,  LATR.  LON,  LONR,  ALT,  ALTR, 

c 

LLPX, 

LLPY,  LLPZ) 

c 

c 

PURPOSE : 

EXTRAPOLATES  BOTH  SELF  AND  MASTER  NAVIGATION  SOLUTIONS  INTO  ECEF 

c 

c 

AND  LOCAL  LEVEL  COORDINATE  VALUES. 

c 

c 

INPUTS : 

c 

c 

NAVTOV 

-  Time  of  Validity  of  MASTER  Navigation  solution 

c 

LAT 

-  Latitude  position  [rad] 

c 

LATR 

-  Latitude  rate  [rad/s] 

c 

LON 

-  Longitude  position  [rad] 

c 

LONR 

-  Longitude  rate  [rad/s] 

c 

ALT 

-  Altitude  [m] 

c 

c 

ALTR 

-  Altitude  rate  [m/s] 

c 

c 

OUTPUTS : 

c 

LLPX 

-  Local  level  x- coordinate  value 

c 

LLPy 

-  Local  level  y- coordinate  value 

c 

LLPZ 

-  Local  level  z- coordinate  value 

c 

c 

TLE(3,3) 

-  Local  level  transform  matrix 

c 

STORED  CONSTANTS 

w 

ar 

-  2.09257382  E7  Earth  semi-minor  radius  [ft] 

c 

c 

e22 

-  6.74499984  E-3  Earth  eccentricity  squared 

L, 

c 

c 

LOCAL  VARIABLES 

c 

TEXT 

-  EXTRAPOLATED  TIME 

c 

LATE 

-  EXTRAPOLATED  LATITUDE 

c 

LONE 

-  EXTRAPOLATED  LONGITUDE 

c 

c 

c 

ALTE 

-  EXTRAPOLATED  ALTITUDE 

c 

c 

C####################################################################### 

SUBROUTINE  XFORM_NAV__COORD  (GPSTOV,  NAVTOV,  LAT,  LATR,  LON,  LONR,  ALT,  ALTR, 

1  LLPX, 

LLPY,  LLPZ,  TLE,  MS,  TE) 

IMPLICIT 

NONE 

INTEGER* 4  MS,  TE 

REAL*  8 

SL,  CL,  SP,  CP 

REAL* 8 

GPSTOV,  NAVTOV,  LAT,  LATR,  LON,  LONR,  ALT,  ALTR,  LLPX,  LLPY,  LLPZ 

REAL*  8 

TEXT,  LATE,  LONE,  ALTE,  ECEFXP,  ECEFYP,  ECEFZP 

REAL* 8 

TLE(3,3),  ECEFP(3,1),  LLP(3,1),  REW,  AR,  RAD,  E22 

DATA  AR/2.09257382E7/ 

DATA  E22/6.74499984E-3/ 

DATA  RAD/57.2957795131/ 
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^  EXTRAPOLATE  NAVIGATION  TO  TIME  OF  GPS  MEASURE 

C***************************** ******************************* ******** 


GPSTOV  -  NAVTOV 
0 


C  TEXT  = 

TEXT  = 

LATE  =  LAT 
LONE  =  LON 
ALTE  =  ALT 


i+  LATR*TEXT 
1+  LONR*TEXT 
1+  ALTR*TEXT 


c******************************************************************** 

c 

C  COMPUTE  ECEF  POSITION 

C 

Q* ******************************************************************* 

C  write  (44,*)  DSQRTd.O  -  E22*DSIN(LAT)  **2) 

REW  =  AR/DSQRT(1.0  -  E22*DSIN (LAT) **2 ) 

ECEFXP  =  (REW  +  ALTE) *DCOS (LATE) *DCOS (LONE) 

ECEFYP  =  (REW  +  ALTE) *DCOS (LATE) *DSIN (LONE) 

ECEFZP  =  (  (1.0  -  E22)*REW  +  ALTE) *DSIN (LATE) 

ECEFP(1,1)  =  ECEFXP 
ECEFP(2,1)  =  ECEFYP 
ECEFP(3,1)  =  ECEFZP 

C*************************************** ************* **************** 
C 

£  COMPUTE  TRANSFORMATION  MATRIX  BETWEEN  ECF  AND  LOCAL  LEVEL 

P  AT  REFERENCE  PLATFORM  (WITH  MASTER  NAV) 

C 

C********************************************************* *********** 


IF  (MS.EQ.l)  THEN 

IF  (TE.EQ.l)  THEN 
SL  =  DSIN(LATE) 

CL  =  DCOS(LATE) 

SP  =  DSIN(LONE) 

CP  =  DCOS(LONE) 


TLE(1,1) 

TLE(1,2) 

TLE(1,3) 

TLE(2,1) 

TLE(2,2) 

TLE(2,3) 

TLE(3,1) 

TLE(3,2) 

TLE(3,3) 

ENDIF 

ENDIF 


-SL*CP 

-SL*SP 

CL 

SP 

-CP 

0.0 

CL*CP 

CL*SP 

SL 


C************************** ****************************************** 

c 

C  COMPUTE  POSITION  VECTOR  OF  PLATFORM  IN  LOCAL  LEVEL  COORDINATES 

C 

C**************************************** ********************  ******** 


CALL  DTMAML(TLE,ECEFP,LLP,3,3,3,1,0, 


0) 


LLPX  =  LLP (1,1) 
LLPY  =  LLP (2,1) 
LLPZ  =  LLP (3,1) 


non 
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RETURN 

END 


C####################################################################### 

SUBROUTINE  COMPUTE_LAB_SAT_VIS  (  SAT (NVS) , ECEFXS (K) , ECEFYS (K) , ECEFZS (K) , MLLPX, MLLPY, 
MLLPZ , SLLPX, SLLPY, SLLPZ , TMLLPX , TMLLPY , TMLLPZ , TSLLPX, TSLLPY, TSLLPZ , TLE ( ) , XA (k) , 
SCOUNT,  SATVIS (SCOUNT) ,  EMPR (SCOUNT) ,  ESPR (SCOUNT) ,  TMPR (SCOUNT) ,  TSPR (SCOUNT) , 
CXS(SCOUNT),  CYS(SCOUNT),  CZS (SCOUNT)  ) 


C 

C 

C 

C 

C 

C 

C 

C 

C 

C 

C 

C 

C 

C 

C 

c 

c 

c 

c 

c 

c 

c 

c 

c 


PURPOSE;  RESTRICTS  DGPS  SATELLITE  USAGE  TO  A  SET  OF  SATELLITES  AT  LEAST 

5  DEGREES  ABOVE  THE  HORIZON.  ALSO  COMPUTES  DIRECTION  COSINES  AND 
PSEUDORANGE  VALUES  BETWEEN  MASTER  AND  SELF  TO  ALL  SELECTED  SATELLITES 


INPUTS : 
NVS 

SAT{NVS) 

ECEFXS (K) 

ECEFYS (K) 

ECEFZS (K) 

MLLPX 

MLLPY 

MLLPZ 

SLLPX 

SLLPY 

SLLPZ 

TMLLPX 

TMLLPY 

TMLLPZ 

TSLLPX 

TSLLPY 

TSLLPZ 

TLE (3, 3) 

XA(k) 


Number  visible  satellites  -  common  to  MASTER  and  SELF 

Ordered  array  of  common  visible  satellites 

ECEF  X“Coordinate  for  satellite  K 

ECEF  y-coordinate  for  satellite  K 

ECEF  z-coordinate  for  satellite  K 

ESTIMATED  MASTER  local  level  x- coordinate  value 

ESTIMATED  MASTER  local  level  y-coordinate  value 

ESTIMATED  MASTER  local  level  z-coordinate  value 

ESTIMATED  SLAVE  local  level  X- coordinate  value 

ESTIMATED  SLAVE  local  level  y-coordinate  value 

ESTIMATED  SLAVE  local  level  z-coordinate  value 

TRUE  MASTER  local  level  x- coordinate  value 

TRUE  MASTER  local  level  y-coordinate  value 

TRUE  MASTER  local  level  z-coordinate  value 

TRUE  SLAVE  local  level  x-coordinate  value 

TRUE  SLAVE  local  level  y-coordinate  value 

TRUE  SLAVE  local  level  z-coordinate  value 

Local  Level  transform  matrix 

Refinement  Filter  solution  vector,  k  =  1,7 


OUTPUTS : 

SCOUNT 

SATVIS  (SCOUNT) 
EMPR  (SCOUNT)  - 
ESPR (SCOUNT)  - 
TMPR (SCOUNT)  - 
TSPR (SCOUNT)  - 
CXS (SCOUNT) 

CYS (SCOUNT) 

CZS (SCOUNT) 


Final  number  of  paired  satellites  visible  above  ANGLIM 

-  Ordered  array  of  common  visible  satellites  above  ANGLIM 
PREDICTED  Pseudorange  Vector  to  satellites  from  MASTER 
PREDICTED  Pseudorange  Vector  to  satellites  from  SELF 

TRUE  Pseudorange  Vector  to  satellites  from  MASTER 
TRUE  Pseudorange  Vector  to  satellites  from  SELF 

-  Direction  cosine  x-component 

-  Direction  cosine  y-component 

-  Direction  cosine  z- component 


STORED  CONSTANTS 
ANGLIM  -  5  degrees 


Angle  of  inclination  that  bounds  visibility 


C####################################################################### 

SUBROUTINE  COMPUTE__LAB_SAT__VIS  {  NVS,  SAT,  ECEFXS,  ECEFYS,  ECEFZS,  MLLPX,  MLLPY, 

1  MLLPZ,  SLLPX,  SLLPY,  SLLPZ,  TMLLPX,  TMLLPY,  TMLLPZ,  TSLLPX,  TSLLPY,  TSLLPZ, 

2  TLE,  XA,  SCOUNT,  SATVIS,  EMPR,  ESPR,  TMPR,  TSPR,  CXS,  CYS,  CZS) 


IMPLICIT  NONE 
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INTEGER* 4  K,  SCOUNT,  NVS,  IND,  SATVIS(NVS) 

SAT(NVS),  ECEFXS(NVS),  ECEFYS{NVS),  ECEFZS (NVS) ,  MLLPX,MLLPY,MLLPZ 
SLLPX , SLLPY , SLLPZ , TMLLPX , TMLLPY, TMLLPZ , TSLLPX , TSLLPY , TSLLPZ , TLE ( 3 , 3 ) , XA ( 8 ) 
ECEFS(3,1),  LLSAT(3,1),  LLSATX(NVS),  LLSATY(NVS),  LLSATZ (NVS) 

SDIFF(3),  MDIFF(3),  TSDIFF(3),  TMDIFF(3),  VIS(NVS),  ANGLIM 
EMPR(NVS),  ESPR(NVS),  TMPR(NVS) ,  TSPR (NVS) , CXS (NVS) ,  CYS(NVS),  CZS(NVS) 
ELEV,  ELEVD,  RAD 

DATA  ANGLIM/8.726646158107211E-002/ 

SCOUNT  =  0 

DO  400  K  =  1,NVS 

ECEFS(1,1)  =  ECEFXS(K) 

ECEFS(2,1)  =  ECEFYS(K) 

ECEFS(3,1)  =  ECEFZS (K) 

CALL  DTMAML ( TLE , ECEFS , LLSAT ,3, 3, 3, 1,0,0) 

LLSATX(K)  =  LLSAT (1,1) 

LLSATY(K)  =  LLSAT (2,1) 

LLSATZ (K)  =  LLSAT (3,1) 


REAL* 8 
REAL* 8 
REAL* 8 
REAL* 8 
REAL* 8 
REAL* 8 


C 

C  COMPUTE  DIFFERENCE  VECTOR  BETWEEN  SATELLITE  AND  PLATFORM 

C  TEST  FOR  POSITIVE  Z  VALUE 

C  IF  POSITIVE,  THEN  TEST  FOR  ELEVATION  ANGLE 

C 


SDIFFd)  =  LLSATX(K)  -  SLLPX  +  XA(1) 
SDIFF(2)  =  LLSATY(K)  -  SLLPY  +  XA(3) 
SDIFF(3)  =  LLSATZ (K)  -  SLLPZ  +  XA(5) 


TMDIFF(l)  =  LLSATX(K)  -  TMLLPX 

TMDIFF(2)  =  LLSATY(K)  -  TMLLPY 

TMDIFF(3)  =  LLSATZ (K)  -  TMLLPZ 


IF(SDIFF(3)  .LT.OJTHEN 
VIS(K)  =  0 
GO  TO  450 
ELSE 

ELEV  =  DATAN2(TMDIFF(3) ,  DSQRT (TMDIFF (1) **2  +  TMDIFF (2) **2) ) 
ELEVD  =  ELEV*RAD 


IP{  ELEV. GE. ANGLIM)  THEN 
VIS(K)  =  1 
SCOUNT  =  SCOUNT  +  1 
C  IND  =  SCOUNT 

SATVIS (SCOUNT)  =  K  !  without  IND,  SCOUNT  becomes  2931471920874901274902178 
c  SCOUNT  =  IND 

TMPR(K)  =  DSQRT (TMDIFF (1) **2  +  TMDIFF(2)**2  +  TMDIFF (3) **2) 

ESPR(K)  =  DSQRT (SDIFF (1) **2  +  SDIFF(2)**2  +  SDIFF(3)**2) 


COMPUTE  DIRECTION  COSINES 


************************************ 

FROM  PLATFORM  1  TO  ALL  VISIBLE  SATELLITES 


C 


Appendix  B  -  Code  Listing 


Page  B31 


CXS(K)  =  SDIFF(1)/ESPR(K) 
CYS(K)  =  SDIFF(2)/ESPR(K) 
CZS(K)  =  SDIFF(3)/ESPR(K) 


C******************************************************************** 

C 

C  COMPUTE  TRUE  RANGE  FROM  SATELLITES  TO  MASTER  AND  SLAVE 

C 

C******************************************************************** 


TSDIFF(l)  =  LLSATX(K)  -  TSLLPX 
TSDIFF(2)  =  LLSATy(K)  -  TSLLPY 
TSDIFFO)  =  LLSATZ(K)  -  TSLLPZ 

TSPR(K)  =  DSQRT(TSDIFF(1) **2  +  TSDIFF{2)**2  +  TSDIFF (3) **2) 

MDIFF(l)  =  LLSATX(K)  -  MLLPX 
MDIFF(2)  =  LLSATY(K)  -  MLLPY 
MDIFF(3)  =  LLSATZ(K)  -  MLLPZ 

EMPR(K)  =  DSQRT(MDIFF(1)**2  +  MDIFF(2)**2  +  MDIFF(3)**2) 


ELSE 

VIS(K)  =  0 
ENDIF 


ENDIF 


IF 

(SCOUNT.  GT.  10)  THEN 

SCOUNT  =  10 

ENDIF 

• 

450 

CONTINUE 

400 

CONTINUE 

RETURN 

END 


C####################################################################### 

C  SUBROUTINE  PROCESS_PR_DATA  (  SCOUNT,  SATVIS,  NVS,  PRRl,  PRR2,  MPGPSTM 
C  SPGPSTM,  EMPR,  ESPR  ) 

C 

C  PURPOSE:  PERFORMS  A  CONVERSION  OF  SATELLITE  CODEPHASE  DATA  TO  GENERATE  AN  ARRAY 
C  OF  PSEUDORANGE  DATA  BETWEEN  THE  MASTER  OR  SELF  AND  COMMON  VISIBLE  SATELLITES. 

C 
C 

C  INPUTS : 

C 

C  SCOUNT 
C  SATVIS (K), 

C  NVS 
C  PRRl(j) 

C  PRR2(j) 

C  MPGPSTM(j) 

C  SPGPSTM(j) 

4l 

C  OUTPUTS : 

C 


Final  paired  satellite  count  satisfying  elevation  criteria 

-  K=l, SCOUNT  Satellite  Visibility  vector 

Number  of  satellites  paired,  but  not  yet  checked  for  elevation 

-  j=l,NVS  MASTER  sorted  code  phase  data 

-  j=l,NVS  SELF  sorted  code  phase  data 

-  j=l,NVS  MASTER  sorted  predicted  GPS  time  vector 
~  j=l,NVS  SELF  sorted  predicted  GPS  time  vector 
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C  EMPR(K)  -  MASTER  predicted  pseudorange  vector  [in] 

ESPR(K)  -  SELF  predicted  pseudorange  vector  [m] 

C 

C  STORED  CONSTANTS 

C  C  “  2.99792498  E8  [m/s]  Speed  of  light 

C  CR  -  TBD  Code  Phase  conversion  constant 

C 
C 

c####################################################################### 

SUBROUTINE  PROCESS_PR_DATA  (  SCOUNT,  SATVIS,  NVS,  PRRl,  PRR2,  MGPSTOV, 

1  SGPSTOV,  EMPR,  ESPR  ) 

IMPLICIT  NONE 

INTEGER* 4  SCOUNT,  NVS,  I,  K,  I POPS 

REAL*8  PRRl (NVS),  PRR2 (NVS) ,  MGPSTOV (NVS) ,  SGPSTOV (NVS ) ,  EMPR (NVS),  ESPR (NVS) 
REAL*8  PGPSTM(NVS),  PRR(NVS),  PGPST,  CDPHSE,  PRSEC  ,  SATVIS (SCOUNT) 

REAL* 8  C,  CR,  FPGPS 

DATA  C/2.99792498E8/ 

DATA  CR/1/ 


DO  I  =  1,NVS 

PGPSTM(I)  =  MGPSTOV (I) 
PRR(I)  =  PRRl (I) 

END  DO 


^  DO  500  K  =  1, SCOUNT 
P  PGPST  =  PGPSTM (SATVIS (K) ) 

CDPHSE  =  PRR (SATVIS (K) ) 

IPGPS  =  PGPST 

FPGPS  =  PGPST  -  FLOAT (IPGPS) 
PRSEC  =  FPGPS  -  (CDPHSE/CR) 
IF  (PRSEC.lt. 0.0)  THEN 
PRSEC  =  1.0  +  PRSEC 
ENDIF 

EMPR(K)  =  PRSEC*C 
500  CONTINUE 


DO  I  =  1,NVS 

PGPSTM (I)  =  SGPSTOV (I) 
PRR (I)  =  PRR2(I) 

END  DO 


DO  550  K  =  1, SCOUNT 

PGPST  =  PGPSTM(SATVIS(K) ) 
CDPHSE  =  PRR (SATVIS (K) ) 

IPGPS  =  PGPST 

FPGPS  =  PGPST  -  FLOAT (IPGPS) 
PRSEC  =  FPGPS  -  (CDPHSE/CR) 
IF  (PRSEC.lt. 0.0)  THEN 
PRSEC  =  1.0  +  PRSEC 
ENDIF 

ESPR(K)  =  PRSEC*C 


550  CONTINUE 
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RETURN 

END 


C####################################################################### 

C  SUBROUTINE  GENERATE_KALMAN_OBS_SET  (  SCOUNT,  EMPR,  ESPR,  TMPR,  TSPR,  SATVIS,  MLLPX, 

MLLPY,  MLLPZ,  SLLPX,  SLLPY,  SLLPZ,  TMLLPX,  TMLLPY,  TMLLPZ,  TSLLPX,  TSLLPY,  TSLLPZ, 
BPR2M,  BBC2M,  TC,  RF_STATE,  XA,  HA,  YA,  YAEXP,  SATVIS,  DXTRUE,  DYTRUE,  DZTRUE  ) 


C 

C 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


PURPOSE:  PERFORMS  A  CONVERSION  OF  SATELLITE  CODEPHASE  DATA  TO  GENERATE  AN  ARRAY 

OF  PSEUDORANGE  DATA  BETWEEN  THE  MASTER  OR  SELF  AND  COMMON  VISIBLE  SATELLITES. 


INPUTS : 

SCOUNT*  Number  of  selected  observations 

EMPR  (SCOUNT)  *  EST  (predicted)  pseudorange  array  from  MASTER 
ESPR  (SCOUNT)  *EST  (predicted)  pseudorange  array  from  SELF 
TMPR  (SCOUNT)  *  TRUE  (measured)  pseudorange  array  from  MASTER 
TSPR  (SCOUNT)  *  TRUE  (measured)  pseudorange  array  from  SELF 
SATVIS  (K)  * 

MLLPX 
MLLPY 
MLLPZ 
SLLPX 
SLLPY 
SLLPZ 
TMLLPX 
TMLLPY 
TMLLPZ 
TSLLPX 
TSLLPY 
TSLLPZ 


BPR2M** 

BBC2M** 

TC 

RF_STATE 

X(A) 


OUTPUTS : 

HA(12,8) 

YA(12) 

YAEXP(14) 

SCOUNT 

TC 

SATVIS  (K)* 
DXTRUE 
DYTRUE 
DZTRUE 


K  =  1,  NS  Satellite  Visibility  vector 
ESTIMATED  MASTER  local  level  x-coordinate  value 
ESTIMATED  MASTER  local  level  y- coordinate  value 
ESTIMATED  MASTER  local  level  z -coordinate  value 
ESTIMATED  SLAVE  local  level  X- coordinate  value 
ESTIMATED  SLAVE  local  level  y-coordinate  value 
ESTIMATED  SLAVE  local  level  z- coordinate  value 
TRUE  MASTER  local  level  X- coordinate  value 
TRUE  MASTER  local  level  y-coordinate  value 
TRUE  MASTER  local  level  z- coordinate  value 
TRUE  SLAVE  local  level  x-coordinate  value 
TRUE  SLAVE  local  level  y-coordinate  value 
TRUE  SLAVE  local  level  z-coordinate  value 

Backup  measured  range  to  master 

Backup  measured  clock  bias  to  master 

Observation  set  time  of  validity 
State  of  the  refinement  filter 
A  =  1,  8  Current  RF  state  vector 


Observation  matrix  for  Kalman  Filter 
Inputs  to  the  Kalman  Filter 
Expected  Kalman  solutions 
Number  of  selected  observations 
Observation  set  time  of  validity 

K  =  1,  NS  Satellite  Visibility  vector 
TRUE  Error  composite  x-coordinate  value 
TRUE  Error  composite  y-coordinate  value 
TRUE  Error  composite  z-coordinate  value 


STORED  CONSTANTS 

C  -  2.99792498  E8  [m/s]  Speed  of  light 

CR  -  TBD  Code  Phase  conversion  constant 
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c####################################################################### 

P  SUBROUTINE  GENERATE_KALMAN_OBS_SET  {  SCOTWIT,  EMPR,  ESPR,  TMPR,  TSPR,  SATVIS,  MLLPX, 

^  1  MLLPY,  MLLPZ,  SLLPX,  SLLPY,  SLLPZ,  TMLLPX,  TMLLPY,  TMLLPZ,  TSLLPX,  TSLLPY,  TSLLPZ, 

2  BPR2M,  BBC2M,  TC,  RF_STATE,  XA,  HA,  YA,  YAEXP,  DXTRUE,  DYTRUE,  DZTRUE,  BCTRUE,  CXS,  CYS,  CZS) 

IMPLICIT  NONE 

INTEGER*4  SCOUNT,  RP_STATE,  I,  J,  K,  INDEX,  IND,  SATVIS (SCOUNT) ,  IBIAS,  IRANGE,  IX 
REAL*8  EMPR(24),  ESPR(24),  TMPR(24),  TSPR(24) 

REAL* 8  MLLPX,  MLLPY,  MLLPZ,  SLLPX,  SLLPY,  SLLPZ,  TMLLPX,  TMLLPY,  TMLLPZ 

REAL*8  TSLLPX,  TSLLPY,  TSLLPZ,  BPR2M,  BBC2M,  XA(8),  CXS(24),  CYS(24),  CZS(24) 

REAL*8  TC,  HA(12,8),  YA(12) , YAEXP (12) ,  DXTRUE,  DYTRUE,  DZTRUE,  BCTRUE 
REAL* 8  DELEX,  DELEY,  DELEZ,  DELX,  DELY,  DELZ,  RTRAB,  RESAB,  RANGEM 

REAL*8  CM,  CR,  C,  ZEROH,  RNGISG,  QUANT,  EHRNGE,  BIASM,  RAND 

DATA  CM/0.983571194156611/ 

C  DATA  C/2 . 99792498E8/ 

DATA  CR/1/ 

DATA  QUANT/12.5/ 

DATA  IX/12478/ 

DATA  RNGlSG/21.0/ 

DATA  ZEROH/O.ODO/ 


C* ******** *********************************************************** 

c 

C  COMPUTE  TRUE  RANGE  BETWEEN  PLATFORMS  1  AND  2 

C 

p*  ******************************************************************* 

DELX  ^  TSLLPX  -  TMLLPX 
DELY  =  TSLLPY  -  TMLLPY 
DELZ  =  TSLLPZ  -  TMLLPZ 

RTRAB  =  DSQRT(DELX**2  +  DELy**2  +  DELZ**2) 


C*********************** ************************** ******************* 

c 

C  COMPUTE  ESTIMATED  RANGE  BETWEEN  PLATFORMS  1  AND  2  BASED  ON 

C  NAVIGATIONAL  SOLUTIONS,  BUT  NOT  YET  INCLUDING  CLOCK  BIAS 

C 

C************************* ********************************** ********* 


DELEX  =  SLLPX  -  MLLPX 
DELEY  =  SLLPY  -  MLLPY 
DELEZ  =  SLLPZ  -  MLLPZ 

RESAB  =  DSQRT(DELEX**2  +  DELEY**2  +  DELEZ**2) 


C 

C  NAV  ERROR  RESULTS 

C 


DXTRUE  =  DELEX  -  DELX 
DYTRUE  =  DELEY  -  DELY 
DZTRUE  =  DELEZ  -  DELZ 


WRITE{41,600)TC, 


DXTRUE , DYTRUE , DZTRUE 


600 


FORMAT  (IH  4(1X,E14.8)) 
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c 

c 

c 

c 

c 

c 


(BEGINNING  OF  MEASUREMENT  PROCESSING  INNER  LOOP) 

COMPUTE  EXPECTED  AND  OBSERVED  MEASUREMENTS  FOR  AUXILIARY  FILTER 

NOTE  THAT  RANGE  AND  TIME  MEASUREMENTS  ARE  QUANTIZED  TO  12 . 5ns  FOR  LINK  16  DERIVED  DATA 


C  RANGEM  =  RTRAB  +  BCTRUE*C  +  GAUSSIAN  NOISE  TERM 


RANGEM  =  RTRAB  +  BCTRUE*CM 
CALL  GAUSKX(IX,RNG1SG,ZER0H,RAND) 


RANGEM  =  RANGEM  +  RAND 

IRANGE  =  RANGEM/QUANT 
YA(1)  =  FLOAT (IRANGE) *QUANT 

EHRNGE  =  DSQRT(DELEX**2  +  DELEY**2) 

YAEXP(l)  =  EHRNGE  +  XA(7)*CM  !YAEXP(1)  =  RESAB 

C  BC  MEASURED  IS  BCTRUE  +  GAUSSIAN  NOISE  TERM 

BIASM  =  BCTRUE 
IB IAS  =  B I ASM/QUANT 

•  YA(2)  =  FLOAT  ( IBIAS )  *QUANT 

YAEXP(2)  =  XA(7) 


C***************************************** ******************* ******** 

C 

C  COMPUTE  DGPS  MEASURED  (YA)  AND  PREDICTED  (YAEXP)  VALUES 

C 

C* ************** ***************************************************** 

DO  610  J  ^  l,SCOUNT 
INDEX  =  J  +  2 

YA(INDEX)  =  TSPR(SATVIS(J) )  -  TMPR (SATVIS ( J) )  +  BCTRUE  *  CM 
YAEXP (INDEX) =  ESPR (SATVIS (J) )  -  EMPR (SATVIS (J) )  +  XA(7)  *  CM 

610  CONTINUE 


DO  620  I  =  1,12 
DO  620  J  ==  1,8 
HA(I,J)  =  0.0 
620  CONTINUE 


C* ********************************************* ************ ********** 

C 

C  RANGE  PARTIAL  DERIVATIVES 


HA  (1,1)  =  DELX/RESAB 
IF(ABS(HA(1,1) ) .LT. 1.3) THEN 


non 
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=  0.0 

ENDIF 

HA (1,3)  =  DELY/RESAB 
IF(ABS (HA (1,3)) .LT. 1.3) THEN 
HA(1,3)  =  0.0 
ENDIF 

HA (1,5)  =  DELZ/RESAB 
IF(ABS(HA(1,5) ) .LT.1.3)THEN 
HA(1,5)  =  0.0 
ENDIF 


CLOCK  BIAS  PARTIAL  DERIVATIVE 

C************ ******************************************************** 


HA(2,7)  =  0.0 


C******************************************************************** 

C 

C  DELTA  PSEDDORANGE  PARTIAL  DERIVATIVE 

C  USE  SATELLITES  INDEXED  BY  VECTOR  SATVIS(24) 

C 

C*************************************** ************** *************** 


DO  650  J  =  l,SCOUNT 
INDEX  =  2  +  J 
C  IND  =  SATVIS(J) 
k  HA (INDEX, 1)  =  CXS (SATVIS ( J) ) 

P  HA (INDEX, 3)  =  CYS (SATVIS (J) ) 

HA (INDEX, 5)  =  CZS (SATVIS (J) ) 

IF(ABS(CXS (SATVIS (J) ) ) .LT. .6) THEN 
HA(INDEX,1)  =  0.0 
ENDIF 

IF (ABS (CYS (SATVIS (J))) .LT..6)THEN 
HA(INDEX,3)  =  0.0 
ENDIF 

IF (ABS (CZS (SATVIS (J) ) ) .LT. .6) THEN 
HA(INDEX,5)  =0.0 
ENDIF 

HA(INDEX,7)  =  CM 
650  CONTINUE 


RETURN 

END 


SUBROUTINE  GAUSKX (IX, S , AM, 


V) 


INTEGER* 4  IX 
REAL*8  S,AM,V,A 
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ccccccccccccccccccccccccccccccccccccccccccccccccccccccccc 
jC  S  =  STANDARD  DEV  DESIRED 
P  AM  =  MEAN  DESIRED 

C  V  =  VALUE  OF  COMPUTED  RANDOM  VARIABLE 

ccccccccccccccccccccccccccccccccccccccccccccccccccccccccc 

M  =  2147483647 
A  =  0.0 
DO  50  1=1,12 
CALL  LEHMER(IX) 

A  =  A+DFLOAT(IX)/M 
50  CONTINUE 

V  =  (A-6.0D0)*S  +  AM 

RETURN 

END 


C======= 


SUBROUTINE  LEHMER(SEED) 

INTEGER*4  SEED,  A,Z,M,R,Q,  HI,  LO,  TEST 

A  =16807 
M  =  2147483647 
Q  =  127773 
R  =  2836 
HI=  SEED/Q 
LO=  MOD (SEED, Q) 

TEST  =  A*LO  -  R*HI 

IF(TEST.GT.O)  THEN 
SEED  =  TEST 
ELSE 

SEED  =  TEST+M 
ENDIF 

RETURN 

END 


C* 

C 

C 

C 

C 

C 

C 

C 

C 

C 

C 

C 

C 

C 

c 

c 

c 

c 


c 

c 

c 


VERSION  NO.  1.0  DATE:  24  FEBRUARY  2003 

PURPOSE:  PERFORMS  THE  EXTENDED  KALMAN  FILTERING  PROCESSES  NEEDED  TO  ESTIMATE  THE  NUMERIC 

VALUES  OF  THE  EIGHT  REFINEMENT  FILTER  ERROR  TERMS  CONTAINED  IN  STATE  VECTOR  XA. 


INPUTS : 

PA(8,8) 

PHIA(8,8) 

RA(12,12) 

QA{8,8) 

HA(12,8) 

SCOUNT 

YA{  INDEX) 

YAEXP (INDEX) 

TC 

DXTRUE 

DYTRUE 

DZTRUE 

BCTRUE 

FCTRUE 


-  Covariance  Matrix 

”  State  transition  Matrix 
“  Measurement  Error 

-  Process  Noise 

-  Observation  matrix 

-  Final  number  of  paired  satellites  visible  above  ANGLIM 

”  INDEX  =1,  14  Observation  measurement  vector 

-  INDEX  =  1,  14  Observation  prediction  vector 

-  Reference  time  at  which  measurements  are  valid  since  GPS  time  of  week  [s] 


-  True  error  composites. 

-  TRUE  clock  bias 

-  TRUE  frequency  drift 
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OUTPUTS : 

RF  RESULTS  PKG 


STORED  CONSTANTS: 

POSX  =  (1000.0) **2  Initial  Position  Covariance  Constant  [m2] 

BCX  =  (100.0) **2  Initial  Clock  Bias  Covariance  Constant  [ns2] 

PCX  =  (10.0) **2  Initial  Freq  Drift  Covariance  Constant  [ns2/sec2] 

PNX  =  (1000.0) **2  Process  Noise  Position  Constant  [m2] 

BCPNX  =  (10.0) **2  Process  Noise  Clock  Bias  Constant  [ns2] 

FCPNX  =  (1.0) **2  Process  Noise  Freq  Drift  Constant  [ns2/sec2] 

RNX  =  (21.0) **2  Range  Measurement  Variance  Constant  [m2] 

RNX2  =  (12.5) **2  RTT  Clock  Bias  Measurement  Variance  Constant  [ns2] 

RNX3  =  (4.0) DGPS  Measurement  Variance  Constant  [m2] 

SSLIM  =  TBD  Steady  State  Indication  [m] 


CALLED  BY: 

RF  EXEC  CTRL 


SUBROUTINES : 


MODICATION  HISTORY: 

VI.  0  ORIGINAL  VERSION  DATE  RESPONSIBLE 

FOR  VERSION  1.0  4/03/03  JYH 


SUBROUTINE  RF_KALMAN_PROC  ( PA ,  PHIA,  RA,  QA,  HA,  SCOUNT,  YA,  YAEXP,  TC,  TOLD, 
1  DXTRUE,  DYTRUE,  DZTRUE,  BCTRUE,  FCTRUE,  XA) 

C**************** ******** ************* **************** *************** 

C 

C  DECLARATION  OF  VARIABLES 

C 

C* ******************************************************************* 

C  COMMON  SCOUNT,  TC 
IMPLICIT  NONE 
REAL*8  yA(12) , YAEXP (12) 

REAL*8  PHIA(8,8) ,PA(8,8) ,QA(8,8) ,RA(12,12) ,XA(8) 

REAL*8  RSL(12) ,DTA(8) 

REAL* 8  TC,  TOLD,  TEXT 

REAL*  8  DXTRUE , DYTRUE , DZTRXJE , BCTRUE , FCTRUE 
REAL*8  SIGX,SIGY,SIGZ,SIGBC 
REAL*  8  ERRX , ERRY , ERRZ , ERRBC , ERRFC 

•REAL*8  HA(12,8) ,DUM3 (8,8) 

REAL*8  G(8,12) ,DUM(8,12) ,DUM1(12,12) , DENOM (12 , 12) ,DUM2(8,8) 

INTEGER*4  LW (12) ,NW (12) , SCOUNT, DIMLIM,  I,J,K 
REAL*8  DUMX(8,8) ,M(8, 8)  ,D 
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c* 


c 

C  COMPUTE  KALMAN  GAIN  MATRIX  G(8,12) 

C 

C******************************** ************** ********* ******* ****** 


CALL  DTMAML(PA,HA,DUM,8,8,12,8,0,1) 

CALL  DTMAML(HA,DUM,DENOM,12,8,8,12,0,0) 

DO  200  I  =  1,12 
DO  200  J  =  1,12 

DUM1(I,J)  =  DENOM{I,J)  +  RA(I,J) 

200  CONTINUE 

CALL  DMINV1(DUM1,12,D) 

CALL  DTMAML(DUM,DUM1,G,8,12,12,12,0,0) 

C***************** ****************************************** ********* 

c 

C  APPLY  KALMAN  STATE  CORRECTION  -  COMPUTE  RESIDUAL 

C 

C**************** ****************************************** ********** 


DIMLIM  =  2  +  SCOUNT 
DO  202  I  =  1, DIMLIM 
RSL(I)  =  YA(I)  -  YAEXP(I) 


F202 


CONTINUE 


C******** ******************************************* ***************** 

c 

C  APPLY  KALMAN  STATE  CORRECTION  -  COMPUTE  RF  STATE  INCREMENTS 

C 

C************************************* ****************** ************* 


DO  205  I  =  1,8 
DTA(I)  =  0.0 
DO  205  J  =  1, DIMLIM 

DTA(I)  =  DTA(I)  +  G(I, J) *RSL(J) 

205  CONTINUE 


C**************** ******************* *★*****★★ ************ ************ 

c 

C  APPLY  KALMAN  STATE  CORRECTION  -  UPDATE  RF  STATE  VECTOR 

C 

C* **************************** *************************************** 


C 

C 


DO  2205  I  =  1,8 

IF(TC.GT.30. .AND.ABS (DTA(I) ) .LT.1.0)THEN 
DO  2206  J  =  1,12 
G(I,J)  =  0.0 
DTA(I)  =  0.0 
2206  CONTINUE 
I  ENDIF 

2205  CONTINUE 


DO  206  I  =  1,8 
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XA(I)  =  XA{I)  +  DTA(I) 
206  CONTINUE 
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c**************************************** **************************** 

c 

C  GENERATE  ERROR  TERMS  FOR  STATUS  REPORT 

C 

C****************** ***************************************** ********* 


ERRX  =  XA(1)  -  DXTRUE 
ERRY  =  XA(3)  -  DYTRUE 

ERRZ  =  XA(5)  -  DZTRUE 

ERRBC  =  XA(7)  -  BCTRUE 
ERRFC  =  XA(8)  -  FCTRUE 


C************ ************************************************ ******** 

C 

C  OBSERVATION  UPDATE  OF  COVARIANCE  MATRIX  PA 

C 

C************************** ******************** ********************** 


CALL  DTMAML(G,HA,DUM2,8,12,12,8,0,0) 

DO  220  I  =  1,8 
DO  220  J  =  1,8 
DUM2(I,J)  =  -DUM2(I,J) 

220  CONTINUE 

DO  225  I  =  1,8 

k  DUM2(I,I)  =  1.0  +  DUM2(I,I) 

^225  CONTINUE 

CALL  DTMAML(DUM2,PA,DUM3,8,8,8,8,0,0) 

DO  230  I  =  1,8 
DO  230  J  =  1,8 
PA(I,J)  =  DDM3(I,J) 

230  CONTINUE 

C************************* ******************** *********************** 

C 

C  COMPUTE  COVARIANCE  DIAGONAL  SQUARE  ROOTS 

C 

C******************************* ***************************** ******** 


SIGX  =  DSQRT(PA(1,1) ) 
SIGY  =  DSQRT{PA(3,3) ) 
SIGZ  =  DSQRT{PA(5,5) ) 
SIGBC=  DSQRT(PA(7,7) ) 


C************************************** **************  **************** 

C 

C  TIME  EXTRAPOLATE  COVARIANCE  ONE  TIME  STEP 

C 

C* ******************************************************************* 

C  TEXT  =  TC-TOLD 

CALL  DTMAML(PHIA,PA,DUMX,8,8,8,8,0,0) 

CALL  DTMAML(DUMX,PHIA,M,8,8,8,8,0,1) 

M  DO  240  I  =  1,8 
^  DO  240  J  =  1,8 


PA(I,J)  =  M(I,J)  +  QA(I,J) 
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240  CONTINUE 


(tnod(tc, 2000.0)  .lt.l.0e-5)then 
do  1235  i  =  1,8 


do  1235  j  =  1,8 
pa(i,j)  =  0.0 

1235  continue 

do  1236  i  =  1,5,2 
pa(i,i)  =  (10.0)**2 

1236  continue 
pa(7,7)  =  (10.0)**2 
pa(8,8)  =  (2.0)**2 

end  if 


C************************************* *********************** ******** 

C 

C  TIME  EXTRAPOLATE  FILTER  STATES  BY  ONE  STEP 

C 

C*************** ***************************** ****** ****************** 

XA(1)  =  XA(1)  +  XA{2)*0.25 

XA(3)  =  XA(3)  +  XA(4)*0.25 

XA(5)  =  XA(5)  +  XA(6)*0.25 

XA(7)  =  XA(7)  +  XA(8)*0.25 

(;;**★*******************★************♦******************************** 
C  WRITE  OUTPUT  DATA  TO  FILE 

C***************************************** ****** ******* ******* ******* 


• 

WRITE(61,*) 
WRITE(71,*) 
WRITE (63,*) 

TC,ERRX 

T,SIGX 

TC,ERRY 

c 

WRITE (73,*) 
WRITE (65,*) 

T,SIGY 

TC,ERRZ 

c 

WRITE(75,*) 

T,SIGZ 

c 

WRITE (67,*) 

T,ERRBC 

c 

WRITE(77,*) 

RETURN 

END 

T,SIGBC 

c- 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


c 

c 

c 


SUBROUTINE  OCP_INT_PROC  ( MS_IND ,  LF_IND ,  MNAVTOV ,  MLAT ,  MNVEL ,  MLON ,  ME VEL ,  MALT ,  MALTR , 
GPS__HEALTH__IND,  MGPSTOV,  BLCK,  UMSAT  (BLCK)  ,UMPRR  (BLCK)  ,  TMNAVTOV,  TMLAT,  TMNVEL, 
TMLON,  TMEVEL,  TMALT,  TMALTR,  SNAVTOV,  SLAT,  SNVEL,  SLON,  SEVEL,  SALT,  SALTR, 

TSNAVTOV,  TSLAT,  TSNVEL,  TSLON,  TSEVEL,  TSALT,  TSALTR,  BCTRUE,  FCTRUE) 


VERSION  NO.  1.0  DATE:  24  FEBRUARY  2003 

PURPOSE:  TO  SERVE  AS  AN  EXECUTIVE  CONTROL  OF  THE  REFINEMENT  PROCESS.  THIS 

CSC  IS  THE  ONLY  INTERFACE  TO  THE  HOST__INTERFACE_PROC  AND  OCP_INT_PROC 


INPUTS : 

MS_IND 
CSCI  VERSION 
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-  Master/Slave  Indicator 
“  Version  Indicator 


o  n 
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c 

MASTER_MSG 

MMS 

C  TRUE_MNAV 
C  TMNAVTOV 

C  TMLAT 

C  TMNVEL 

C  TMLON 

C  TMEVEL 

C  TMALT 

C  TMALTR 

C 

C  EST^SNAV 
C  SNAVTOV 

C  SLAT 

C  SNVEL 

C  SLON 

C  SEVEL 

C  SALT 

C  SALTR 

C 

C  TRUE_SNAV 
C  TSNAVTOV 

C  TSLAT 

C  TSNVEL 

C  TSLON 

C  TSEVEL 

C  TSALT 

C  TSALTR 

C  BCTRUE 

FCTRUE 


-  RECEIVED  MASTER  MESSAGE 

-  Master  Message  Signal  indicator 

-  TRUE  Time  of  Validity  of  MASTER  Navigation  solution 

-  TRUE  MASTER  Latitude  position  [rad] 

-  TRUE  MASTER  North  Velocity  [ft/s] 

“*  TRUE  MASTER  Longitude  position  [rad] 

-  TRUE  MASTER  East  Velocity  [ft/s] 

-  TRUE  MASTER  Altitude  [ft] 

-  TRUE  MASTER  Altitude  rate  [ft/s] 


-  Time  of  Validity  of  SELF  Navigation  solution 

-  ESTIMATED  SELF  Latitude  position  [rad] 

-  ESTIMATED  SELF  North  Velocity  [ft/s] 

-  ESTIMATED  SELF  Longitude  position  [rad] 

-  ESTIMATED  SELF  East  Velocity  [ft/s] 

-  ESTIMATED  SELF  Altitude  [ft] 

-  ESTIMATED  SELF  Altitude  rate  [ft/s] 


-  TRUE  Time  of  Validity  of  SELF  Navigation  solution 

-  TRUE  SELF  Latitude  position  [rad] 

-  TRUE  SELF  North  Velocity  [ft/s] 

-  TRUE  SELF  Longitude  position  [rad] 

-  TRUE  SELF  East  Velocity  [ft/s] 

-  TRUE  SELF  Altitude  [ft] 

-  TRUE  SELF  Altitude  rate  [ft/s] 

-  TRUE  clock  bias 

-  TRUE  frequency  drift. 


OUTPUTS : 

MNAV__DATA  (MASTER  NAV  DATA  PACKAGE) 

MNAVTOV  -  Time  of  Validity  of  MASTER  Navigation  solution 

MLAT  -  ESTIMATED  MASTER  Latitude  position  [rad] 

MLATR  “  ESTIMATED  MASTER  Latitude  rate  [rad/s] 

MLON  -  ESTIMATED  MASTER  Longitude  position  [rad] 

MLONR  -  ESTIMATED  MASTER  Longitude  rate  [rad/s] 

MALT  -  ESTIMATED  MASTER  Altitude  [m] 

MALTR  -  ESTIMATED  MASTER  Altitude  rate  [m/s] 

TMLAT  -  TRUE  MASTER  Latitude  position  [rad] 

TMLATR  -  TRUE  MASTER  Latitude  rate  [rad/s] 

TMLON  -  TRUE  MASTER  Longitude  position  [rad] 

TMLONR  -  TRUE  MASTER  Longitude  rate  [rad/s] 

TMALT  -  TRUE  MASTER  Altitude  [m] 

TMALTR  -  TRUE  MASTER  Altitude  rate  [m/s] 

MNAV_VAL_IND  -  MASTER  navigation  validity  indicator 

MGPS_DATA 

MSAT(12)  -  MASTER  Ordered  Satellite  List 

MPRR(12)  -  MASTER  Ordered  measured  code  phase  array 

MGPSTOV  -  MASTER  predicted  GPS  time  of  validity 

MVIS  -  Number  of  satellites  visible  to  MASTER 

INVERS(30)  -  Satellite  sorting  index 

SNAV_DATA  (SELF  NAV  DATA  PACKAGE) 

SNAVTOV  -  Time  of  Validity  of  SELF  Navigation  solution 

SLAT  -  ESTIMATED  SELF  Latitude  position  [rad] 

SLATR  -  ESTIMATED  SELF  Latitude  rate  [rad/s] 

SLON  -  ESTIMATED  SELF  Longitude  position  [rad] 

SLONR  -  ESTIMATED  SELF  Longitude  rate  [rad/s] 

SALT  -  ESTIMATED  SELF  Altitude  [m] 


c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 
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SALTR 

TSLAT 

TSIiATR 

TSLON 

TSLONR 

TSALT 

TSALTR 

SNAV  VAL  IND 


ESTIMATED  SELF  Altitude  rate  [m/s] 
TRUE  SELF  Latitude  position  [rad] 
TRUE  SELF  Latitude  rate  [rad/s] 
TRUE  SELF  Longitude  position  [rad] 
TRUE  SELF  Longitude  rate  [rad/s] 
TRUE  SELF  Altitude  [m] 

TRUE  SELF  Altitude  rate  [m/s] 

SELF  navigation  validity  indicator 


STORED  CONSTANTS 

AR  -  2.09257382  E7  Earth  semi-minor  radius  [ft] 

E22  -  6.74499984  E-3  Earth  eccentricity  squared 


SUBROUTINE  OCP_INT_PROC  (MS_IND ,  MMS ,  MASTER__MSG ,  TMNAVTOV,  TMLAT ,  TMNVEL , 

1  TMLON , TMEVEL , TMALT , TMALTR ,  SNAVTOV , SLAT , SNVEL , SLON , SEVEL , SALT , SALTR , 

2  TSNAVTOV,  TSLAT, TSNVEL, TSLON, TSEVEL, TSALT, TSALTR, BCTRUE, FCTRUE) 


VERSION  1  -  NO  MASTER  MESSAGE 


INPUTS:  MS_IND,  TMNAVTOV, TMLAT, TMNVEL, TMLON, TMEVEL, 

TMALT, TMALTR,  SNAVTOV, SLAT, SNVEL, SLON, SEVEL, SALT, SALTR, 
TSNAVTOV ,  TSLAT , TSNVEL , TSLON , TSEVEL , TSALT , TSALTR , BCTRUE , FCTRUE 


LOCAL  VARIABLES: 


GLOBAL  VARIABLES: 


CALLED  BY: 

RF  EXEC  CTRL 


SUBROUTINES : 
PROCESS_MASTER_MES  SAGE 
PROCESS_RAW_GPS_DATA 
CONVERT  NAV  DATA 


MODICATION  HISTORY: 

VI.  0  ORIGINAL  VERSION  DATE  RESPONSIBLE 

FOR  VERSION  1.0  4/03/03  JYH 
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SUBROUTINE  OCP_INT___PROC  (CSCI__VERS_IND,  MS_IND,  MNAVTOV,  MLAT,  MNVEL,  MLON, 

1  MEVEL,  MALT,  MALTR,  TMNAVTOV,  TMLAT,  TMNVEL,  TMLON,  TMEVEL,  TMALT,  TMALTR, 
2  SNAVTOV,  SLAT,  SNVEL,  SLON,  SEVEL,  SALT,  SALTR,  TSNAVTOV,  TSLAT,  TSNVEL, 

3  TSLON,  TSEVEL,  TSALT,  TSALTR,  BCTRUE,  FCTRUE) 


non 
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m  DECLARATION  OF  VARIABLES 

C 


IMPLICIT  NONE 
COMMON  BLCK 
REAL* 8  NC_RATE 

INTEGER*4  CSCI_VERS_IND,  BLCK,  GPS_HEALTH_IND,  MS_IND,  LF_IND,  MMS 
INTEGER*  4  SNAV___VAL_IND ,  MNAV_VAL_IND ,  MVIS 

REAL*8  MNAVTOV,  MLAT,  MNVEL,  MLON,  MEVEL,  MALT,  MLATR,  MLONR,  MALTR,  MGPSTOV 
REAL*8  TMNAVTOV,TMLAT,  TMNVEL, TMLON, TMEVEL, TMALT, TMLATR,  TMLONR , TMALTR 
REAL* 8  SNAVTOV,  SLAT,  SNVEL,  SLON,  SEVEL,  SALT,  SLATR,  SLONR,  SALTR,  SGPSTOV 

REAL*8  TSNAVTOV,TSLAT,  TSNVEL,  TSLON,  TSEVEL,  TSALT,  TSLATR,  TSLONR,  TSALTR 
REAL*8  UMSAT(BLCK) ,UMPRR(BLCK) ,MSAT(BLCK) ,  MPRR{BLCK) ,  INVERS (30) 

REAL* 8  BCTRUE,  FCTRUE 


C - 

c 

C  A  CONSTRUCT  NEEDS  TO  BE  CREATED  FOR  THE  MASTER  MESSAGE 
C 

C - 

REAL* 8  MASTER_MSG 

******************************************************************** 

BEGIN 

******************************************************************** 


IF  (CSCI_VERS_IND.EQ.l)  THEN 
GOTO  100 

ELSEIF  (MS^IND.EQ.l)  THEN 
RETURN 

ELSEIF  (MMS.EQ.O)  THEN 
RETURN 

ELSE 

CALL  PROCESS_MASTER_MSG  (MASTER_MSG,  MNAVTOV,  MLAT,  MNVEL,  MLON,  MEVEL,  MALT, MALTR, 

1  GPS_HEALTH_IND, MGPSTOV, BLCK,  UMSAT,  UMPRR,  TMNAVTOV,  TMLAT,  TMNVEL, TMLON, TMEVEL, TMALT, TMALTR) 

CALL  PROCESS_RAW_GPS_DATA  (BLCK, UMSAT, UMPRR, MSAT,MPRR,  INVERS,  MVIS) 

ENDIF 

IF  (CSCI__VERS_IND.EQ.2)  THEN 
GOTO  100 
ENDIF 

CALL  CONVERT_NAV_DATA(MLAT,  MNVEL,  MEVEL,  MALT,  MALTR,  MLATR,  MLONR) 

CALL  CONVERT_NAV__DATA(SLAT,  SNVEL,  SEVEL,  SALT,  SALTR,  SLATR,  SLONR) 

RETURN 


100 


CONTINUE 


CALL  CONVERT  NAV  DATA (MLAT,  MNVEL,  MEVEL,  MALT,  MALTR,  MLATR,  MLONR) 
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CALL  CONVERT  NAV_DATA (SLAT,  SNVEL,  SEVEL,  SALT,  SALTR,  SLATR,  SLONR) 


CALL  CONVERT_NAV_DATA(TMLAT,  TMNVEL, 
CALL  CONVERT  NAV  DATA(TSLAT,  TSNVEL, 


TMEVEL,  TMALT, 
TSEVEL,  TSALT, 


TMALTR, 

TSALTR, 


TMLATR,  TMLONR) 
TSLATR,  TSLONR) 


RETURN 

END 


C####################################################################### 

C  SUBROUT  INE  PROCE S  S__MAS TER_MSG  ( MNAVSOLN ,  MNAVTOV ,  MLAT ,  MNVEL ,  MLON ,  ME VEL ,  MALT ,  MALTR , 

C  GPS_HEALTH_IND,  MGPSTOV,  BLCK,  UMSAT (BLCK) , UMPRR (BLCK) , TMNAVTOV, TMLAT, 

C  TMNVEL , TMLON , TMEVEL , TMALT , TMALTR ) 

C 

C  PURPOSE:  DECOMPOSES  THE  RECEIVED  MASTER  MESSAGE  INTO  MASTER  NAV  DATA  AND  GPS  DATA. 
C 
C 

C  INPUTS : 

C  MASTER_MSG 

C 

c 

C  OUTPUTS : 

C  MNAVTOV 
C  MLAT 
C  MNVEL 
C  MLON 
C  MEVEL 
C  MALT 
C  MALTR 
C 


-  Master  Message  Time  of  Validity 
ESTIMATED  MASTER  Latitude  position  [rad] 
ESTIMATED  MASTER  North  Velocity  [ft/s] 
ESTIMATED  MASTER  Longitude  position  [rad] 
ESTIMATED  MASTER  East  Velocity  [ft/s] 
ESTIMATED  MASTER  Altitude  [ft] 

ESTIMATED  MASTER  Altitude  rate  [ft/s] 


GPS_HEALTH_ 

MGPSTOV 

BLCK 

UMSAT (BLCK) 
UMPRR (BLCK) 


IND  -  Indicates  the  health  status  of  GPS  signal.  (Binary) 
“  Time  of  Validity  of  MASTER  GPS  solution 
-  Number  of  PR  reports,  size  of  array 

-  Unordered  array  of  MASTER  visible  satellite 

-  Unordered  array  of  MASTER  code  phase 


C 
C 
C 
C 
C 

C####################################################################### 


SUBROUTINE  PROCE SS_MASTER_MSG (MASTER_MSG ,  MNAVTOV, MLAT , MNVEL , MLON , MEVEL , MALT , MALTR , 

1  GPS_HEALTH_IND,  MGPSTOV,  BLCK,  UMSAT, UMPRR,  TMNAVTOV,  TMLAT, 

2  TMNVEL ,  TMLON ,  TMEVEL ,  TMALT ,  TMALTR) 


INTEGER*4  BLCK,  GPS_HEALTH_IND 

REAL*8  MNAVSOLN,  MNAVTOV,  MLAT , MNVEL , MLON , MEVEL , MALT , MALTR ,  MGPSTOV 
REAL*8  UMSAT(12) ,UMPRR(12) , TMNAVTOV, TMLAT,  TMNVEL , TMLON , TMEVEL , TMALT , TMALTR 

REAL*  8  MASTER__MSG 

RETURN 

END 

C####################################################################### 

C  SUBROUTINE  PROCESS_RAW_GPS_DATA  (BLCK,  UMSAT  (BLCK)  ,  UMPRR  (BLCK)  ,  MS  AT  (BLCK)  ,  MPRR  (BLCK)  , 
C  INVERSOO)) 

C 

C  PURPOSE:  PROVIDES  ORDERED  ARRAYS  OF  INPUTED  SATELLLITE  ID’S  AND  CODE  PHASE  DATA 
C 

C  INPUTS : 

£  BLCK  -  Number  of  PR  reports,  size  of  array 

m  UMSAT (BLCK)  -  Unordered  array  of  MASTER  visible  satellite 

?  UMPRR  (BLCK)  -  Unordered  array  of  MASTER  code  phase 
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OUTPUTS : 
MSAT (BLCK) 
MPRR (BLCK) 


-  Ordered  array  of  MASTER 

-  Ordered  array  of  MASTER 


visible  satellite 
code  phase 


C 

C####################################################################### 
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INTEGER*4  I,J,  ID,  BLCK,  MVIS 

REAL*8  PRR,  UMSAT (BLCK) , UMPRR (BLCK) , MSAT (BLCK) , MPRR (BLCK) ,  INVERS (30) 

C******************************** ********* *************************** 

C 

C  SORT  SATELLITE  ID  AND  CODE  PHASE  ARRAYS 

C 

c* ******************************************************************* 


DO  210  J  =  1,  BLCK 
ID  =  UMSAT (J) ; 
PRR  =  UMPRR (J) 


DO  211  I  =  J-1,  0,  -1 

IF  (UMSAT (I) .GT. ID)  THEN 
GOTO  211 
ELSE 

UMSAT(I+1)  =  UMSAT(I) 
UMPRR(I+1)  =  UMPRR(I) 
ENDIF 

ill  CONTINUE 


UMSAT(I+1)  =  ID 
UMPRR (I+l)  =  PRR 


210  CONTINUE 

MSAT (BLCK)  =  UMSAT (BLCK) 

MPRR (BLCK)  =  UMPRR (BLCK) 

C******************************************************************** 

C 

C  GENERATE  INVERS  ARRAY 

C 

c* ******************************************************************* 


DO  220  J  =  1,12 
ID  =  MSAT(J) 
INVERS (ID)  =  J 
220  CONTINUE 

MVIS  =  BLCK 


RETURN 

END 


C####################################################################### 

C  SUBROUTINE  CONVERT_NAV_DATA (NVEL,  EVEL,  ALT,  ALTR,  LATR,  LONR) 

C 

C  PURPOSE:  CONVERTS  NAV  DATA  FROM  FEET  TO  METERS  TO  BE  CONSISTENT  WITH  THE  UNITS  OF 


GPS  MEASUREMENTS.  GENERATES  LATITUDE  AND  LONGITUDE  RATES. 


C 

C 


INPUTS : 
NVEL 
EVEL 


-  North  Velocity  [ft/s] 

-  East  Velocity  [ft/s] 
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ALT 

ALTR 


-  Altitude  [ft] 

-  Altitude  rate  [ft/s] 


OUTPUTS : 
LATR 
LONR 
ALT 
ALTR 


-  Latitude  rate  [rad/s] 

-  Longitude  rate  [rad/s] 

-  Altitude  [m] 

-  Altitude  rate  [m/s] 


C 

c 
c 
c 
c 
c 
c 
c 
c 
c 

C####################################################################### 
SUBROUTINE  CONVERT  NAV  DATA(LAT,  NVEL,  EVEL,  ALT,  ALTR,  LATR,  LONR) 


STORED  CONSTANTS 

ar  -  2.09257382  E7 

RAD 


Earth  semi-minor  radius  [ft] 


IMPLICIT  NONE 

REAL*8  LAT,  NVEL,  EVEL,  ALT,  ALTR,  LATR,  LONR,  AR,  RAD,  FT_M 

DATA  AR/2.09257382E7  / 

DATA  RAD/57.2957795131/ 

DATA  FT_M/3. 28083991667/ 

LATR  =  NVEL*RAD  /  AR 

LONR  =  {EVEL*RAD) / {AR*COS (LAT) ) 

C  ALT  =  ALT/FT_M 
C  ALTR  =  ALTR/FT__M 

WRITE (44 , * ) LATR, LONR, ALT, ALTR 
WRITE  (44,*)  ” - ” 

^  RETURN 
END 
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The  Test  Bed  2  studies  performed  as  part  of  this  project  relied  upon  the  LNS  to  provide  a 
realistic  representation  of  the  error  dynamics  of  a  mobile  Link- 16  navigation  community.  The 
LNS  has  been  under  development  at  BAE  SYSTEMS,  in  steadily  more  sophisticated  versions  for 
the  past  thirty  years.  Since  the  initiation  of  the  JTIDS  Class  2  terminal  Full  Scale  Development 
in  January  1981,  and  for  every  Link-16  terminal  development  thereafter,  the  LNS  has  been 
maintained  as  the  reference  for  the  Link- 16  operational  navigation  and  synchronization 
algorithms.  By  design  and  convention,  the  algorithms  mechanized  within  the  LNS  exactly 
replicate  the  navigation  algorithms  implemented  in  each  Link- 16  terminal.  The  result  is  a  “gold 
standard”  simulation,  test  and  analysis  tool  which  has  proven  to  be  an  invaluable  asset  for 
algorithm  development,  testing,  and  troubleshooting  of  operational  navigation  problems 
experienced  after  terminal  delivery.  The  accuracy  and  reliability  of  this  remarkable  software 
package  have  been  proven  over  literally  thousands  of  flight  hours  in  every  airborne  platform 
installation  of  Link-16.  Flight  test  data  has  been  analyzed  for,  among  others,  the  F-14,  F-15, 
F/A-18,  Aegis  cruiser  navigation  and  the  UK  Tornado  ADV.  The  LNS  allows  the  user  to 
analyze  individual  platform  performance  as  well  as  community  performance.  (Figure  B-1).  The 
LNS  remains  a  proprietary  asset  of  BAE  SYSTEMS. 

The  use  of  the  LNS  as  an  integral  part  of  the  Test  Bed  2  simulation  package  provides 
assurance  that  the  navigation  errors  presented  to  the  DGPS  RF  algorithm  for  refinement  are  truly 
representative  of  actual  flight  conditions.  The  LNS  has  the  following  features  and  capabilities  ( 
Figure  B  -  2) . 

Variable  community  size  (up  to  96  JTIDS  Units  -  Jus)  in  real  time  on  VAX  Station 
4000  or  PC  environments. 

-  Multiple  independent  trajectories  for  each  JU 

Multiple  independent  navigation  models  for  each  JU,  including  strapdown  INS, 
gimbaled  INS,  GPS/INS,  ADC/AHRS,  Doppler/AHRS 

-  Multiple  independent  synchronization  models  for  each  JU 
Communication  and  transmission  of  RTFs  and  PPLIs  for  each  JU 

-  GPS  navigation  model  for  each  JU 

-  Independent  Link- 16  Navigation  Kalman  Filters  for  each  JU,  exactly  as  mechanized 
in  operational  software. 

-  Other  operational  capabilities,  including  Sensor  Registration,  communication 
jamming  models,  and  sensor  measurement  and  alignment  models. 
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Inertial  Navigation  System  (INS) 
Link16PPLIs/TOAs 
Global  Positioning  System 


Figure  B  - 1:  Platform  Performance 


Figure  B  -  2:  LNS  Features  and  CapabQities 
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As  an  example  of  the  inherent  capabilities  of  the  LNS,  we  present  a  complex  simulation 
involving  an  AEGIS  cruiser  operating  with  two  airborne  members  which  provide  PPLI  messages 
to  the  ship.  The  ship  is  also  processing  GPS  PVT  data  with  an  observation  update  rate  of  once 
per  60  seconds.  The  error  budget  of  the  INS  on  the  ship  is  representative  of  the  WSN-7  INS 
installed  aboard  AEGIS-class  units.  (Figures  B-3a  through  B-3e) 
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•  INS: 

-  Accelerometer  Bias  =  25  |Xg 

-  Gyro  Drift  Bias  =  .0025°/hr 

-  Alignment  not  modeled 

-  Initial  Position  Error  =  0 

-  Initial  Velocity  Error  =  1  fps  (x  and  y) 

-  Initial  Azimuth  Error  =  0.25® 

•  GPS; 

-  Available  every  60  sec 

-  No  error 

•  JTIDS; 

-  PPLIs  available  from  each  source  every  12  seconds 

-  No  errors  in  TOA/PPLIs;  QP=14 

-  Latency  modeled  as  a  constant  time  error  ~  1  second 


Figure  B-3b:  Error  Budgets 


Case  lA; 

Autonomous  GPS/INS  Navigation  Performance 
(with  accurate  GPS) 


GPS/INS  Kalman  Filter: 

•  GPS  Measurement  Noise  =  0.1  nm  (-600  ft) 

•  GPS  available  continuously  @  60  sec  rate 


Figure  B-3c 
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Latitude  Error  Longitude  Error 


Figure  B-3d:  Position  Errors 


Figure  B-3e:  Velocity  Errors 
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Operational  Software  Flow  Diagrams 
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I.  RF_EXEC_CTRL 
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Figure  D-2:  STATE  0  PROCESSING  -  Startup  state  /  RF  reset 
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Filter/variable 

Initialization 


CALL 

HOST  INT_PROC 


RF  OPR_SW 


SET: 

RSI  =  0 

RF_STATE  =  0 


CALL 

OCP  INT_PROC 


SNAV_VAL_ 
IND  =  valid? 


SET: 

RSI=1 

RF  STATE  =  0 


GPS_VAL_ 
IND  =  valid? 


SET: 
RSI  =  3 


CALL 

BUELD.MASTER 

MSG 


GENERATE 

RF_HEALTH_ 

STATUS.MSG 


Figure  D-4:  STATE  1  PROCESSING  -  Master  Designation  /  initialization 
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Filter/variable 

Initialization 


CALL 

HOST  EST.PROC 


RF_OPR_SW 


SET: 

RSI  =  0 

RF_STATE  =  0 


CALL 

OCP_INT_PROC 


SNAV_VAL_ 
IND  =  valid? 


SET: 

RSI=1 

RF_STATE  =  0 


GPS_VAL_ 
IND  =  valid? 


SET: 

RSI  =  3 

RF_STATE  =  0 


MNAV_VAL_ 
IND  =  valid? 


SET: 

RSI  =  2 

RF.STATE  =  0 


SET: 

RSI  =  6 

RF_STATE  =  5 


INSUFFICIENT 


GPS 

Strength/#? 


CALL 

RF_SOURCE_DATA^P 

ROC 


CALL 

RF_KALMAN_PROC 


GENERATE 

RF_HEALTH_ 

STATUS^MSG 


Figure  D-5:  STATE  2  PROCESSING  -  Slave  Designation  /  initialization 
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CALL 

HOST„INT_PROC 


RF_OPR_SW 


SET: 

RSI  =  0 

RF  STATE  =  0 


CALL 

OCP  INT.PROC 


SNAV_VAL_ 
IND  =  valid? 


SET: 

RSI=1 

RF  STATE  =  0 


GPS_VAL_ 
IND  =  valid? 


SET: 

RSI  ==3 

RF_STATE  =  0 


MNAV_VAL_ 
IND  =  valid? 


SET: 

RSI  =  2 

RF_STATE  =  0 


SET: 

RSI  =  6 

RF_ST  ATE  =  5 


^INSUFFICIENT 


GPS 

Strength/#? 


CALL 

RF  SOURCE_DATA_P 
ROC 

1 

CALL 

RF_KALMAN_PROC 

SET: 

RSI  =5 

RF_STATE  =  4 


Steady  State? 


METRIC  <  SSLIM 


GENERATE 
RF_HEALTH_ 
STATUS  MSG 


Figure  D-6:  STATE  3  PROCESSING  -  Slave  Designation  /  GPS  Pseudorange  [not  steady  state] 
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CALL 

HOST_INT_PROC 


RF_OPR_SW 


SET: 

RSI  =  0 

RESTATE  =  0 


CALL 

OCP_INT_PROC 


SNAV_VAL_ 
IND  =  valid? 


SET: 

RSI=1 

RF  STATE=:0 


GPS_VAL_ 
JNT)  = 


SET: 

RSI  =  3 

RF  STATE  =  0 


MNAV_VAL_ 
IND  =  valid? 


SET: 

RSI  =  2 

RF_STATE  =  0 


SET: 

RSI  =  6 

RF_STATE  =  5 


^INSUFnCffiNT 


GPS 

Strength/#? 


CALL 

RF_SOURCE_DATA_P 

ROC 


CALL 

RF  KALMAN.PROC 


GENERATE 

RF_HEALTH_ 

STATUS„MSG 


Figure  D-7:  STATE  4  PROCESSING  -  Slave  Designation  /  GPS  Pseudorange  [steady  state] 
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CALL 

HOST_INT_PROC 


RF_OPR_SW 


SET: 

RSI  =  0 

RF  STATE  =  0 


RTT_REQUEST_ 

IND 


CALL 

OCP_INT_PROC 


SNAV_VAL_ 
IND  =  valid? 


SET: 

RSI=1 

RF_STATE  =  0 


MNAV_VAL_ 
IND  =  valid? 


SET: 

RSI  =  2 

RF_STATE  =  0 


SET: 

RSI  =  4 

RF_STATE  =  2 


SUFFICIENT 


GPS 

Strength/#? 


INSUFnCIENT 


CALL 

RF  SOURCE  DATA_P 
ROC 

CALL 

RF_KALMAN_PROC 

SET: 

RSI  =  7 

RF  STATE  =  6 


Steady  State? 


METRIC  <  SSLIM 


GENERATE 

RF_HEALTH_ 

STATUS_MSG 


Figure  D-8:  STATE  5  PROCESSING  -  Slave  Designation  /  RTT,  PPLI  [backup  mode  initialization] 
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CALL 

HOST  INT.PROC 


RF  OPR_SW 


SET: 

RSI  =  0 

RF  STATE  =  0 


CALL 

OCP_INT_PROC 


SNAV^VAL. 
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Figure  D-9:  STATE  6  PROCESSING  -  Slave  Designation  /  backup  mode  [steady  state] 
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;  FIRST  CALL- USE  EST  j 
i  NAVDATA 

j  _ ^  MLLPX  i 

:  MLLP=MLLPY  j 

!  MLLPZ  _  ^ 

^ _ SLLPX  : 

I  SLLP  =  SLLPY 

I  SLLPZ  ! 

i _ J 


!  SECOND  CALL -USE 
j  TRUE  NAVDATA 

■  _ _  TMLLPX 

!  TMLLP=TMLLPY 

!  _  _  jri^Lre 

^  _ _  TSLLPX 

!  TSLLP  =  TSLLPY 
!  TSLLPZ 


Figure  D-10:  RF_SOURCE_DATA_EXEC  Logical  data  flow  diagram 
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Figure  D-11:  RF_SOURCE_DATA_EXEC  Logical  data  flow  diagram  (cont.) 
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INITIALIZE 
SATVIS  VECTOR 
SETSCOUNT  =  0 


TRANSFORM 
SATELLITE  INDEXED 
BYj 

TO  PLATFORM 
LOCAL  LEVEL 


COMPUTE  EST. 
DIFFERENCE 
VECTOR  BETWEEN 
SAT  (j)  AND  MASTER 


For  all  j,j  =  1,24 


r 

COMPUTE  EST. 
DIFFERENCE 
VECTOR  BETWEEN 
SAT(j)  AND  SELF 

r 

ECEFXSO) 
LLSAT  =  [TLE  ]  *  ECEFYSC) 
ECEFZSG) 
LLSATX 

where  LLSAT  =  LLSATY 


LLSATZ 


DIFF2  (1)  =  LLSATX  ^  SLLPX  +  XA  (1) 
DIFF2  (2)  =  LLSATY  -  SLLPY  +  XA  (3) 
DIFF2  (3)  =  LLSATZ  -  SLLPZ  +  XA  (5) 


DIFFl  (1)  =  LLSATX  -  MLLPX 
DIFFl  (2)  =  LLSATY  -  MLLPY 
DIFFl  (3)  =  LLSATZ  ~  MLLPZ 


COMPUTER 
VISIBILITY  FOR 
SATELLITE  INDEXED 
BYj 


SATELLITE  USABLE  IFF 

DIFF2  (3)  >  0  &  ELEVATION  >  ANGLIM 


i  ELEV  =  ATAN 


DIFF2  (3) 

[DIFF2(1)^+DIFF{2)2]'' 


Satellite 

Visible? 


INCREMENT 

SCOUNTAND 

i 

SET  SATVIS  VECTOR 

1 

SCOUNT  =  SCOUNT+l 


Figure  D-12:  COMPUTE_SAT_LAB_VIS  Logical  data  flow  diagram 
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) 


ESPR  (SCOUNT)  =  [DIFF2  (1)  ^  +  DIFF2  (2)  ^  +  DIFF2  (3) 


EMPR  (SCOUNT)  =  [DIFFl  (1)H  DIFFl  (2)^  +  DIFFl  (3)^]^'^ 


CXS  (SCOUNT)  =  DIFF2  (1)  /  ESPR 
CYS  (SCOUNT)  =  DIFF2  (2)  /  ESPR 
CZS  (SCOUNT)  =  DIFF2  (3)  /  ESPR 


DIFF2  (1)  =  LLSATX  -  TSLLPX 
DIFF2  (2)  =  LLS  ATY  -  TSLLPY 
DIFF2  (3)  =  LLS  ATZ  -  TSLLPZ 


DIFFl  (1)  =  LLSATX  -  TMLLPX 
DIFFl  (2)  =  LLS  ATY  -  TMLLPY 
DIFFl  (3)  =  LLS  ATZ  -  TMLLPZ 


TSPR  (SCOUNT)  =  [DIFF2  (1)^  +  DIFF2  (2)^  +  DIFF2  (3)^]^^^ 


TMPR  (SCOUNT)  =  [DIFFl  (1)  ^  +  DIFFl  (2)  ^  +  DIFFl  (3)  j 

_ _ i 


COMPUTE_SAT_LAB_VIS  Logical  data  flow  diagram  (cont) 
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SETPGPSTM(j)^ 

IF  MASTER  DATA 

=  MPGPSTM(j) 
IF  SLAVE  DATA 

=  SPGPSTM  (  j  ) 

SETPRR(j) 

IF  MASTER  DATA 

=:PRRl(j) 

IF  SLAVE  DATA 

=:PRR2(j) 


LOOP  k=l,SCOUNT 


COMPUTE 
PREDICTED 
GPS  TIME 


;  PGPST  =  PGPSTM(SATVIS(k)) 


SELECT 

CODE 

PHASE 


CDPHSE  =  PRR  (S ATVIS  (k)) 


COMPUTE 
PSEUDORANGE  IN 
SECONDS 


:  IPGPS  =  PGPST 
!  (integer) 

:  FPGPS  =  PGPST- FLOAT  (IPGPS) 
i  PRSEC  =  FPGPS-(CDPHS/CR) 


ADJUST 

PRSEC 


IF  (PRSEC.lt.  0.0)  THEN 
PRSEC  =1.0  + PRSEC 
ENDIF 


EMPR  (k)  = 
PRSEC  *  C 


MASTER/ 
SLAVE 
D 


ESPR(k)  = 
PRSEC  *  C 


END  LOOP 


Figure  D-13:  PROCESS_PR_DATA  Logical  data  flow  diagram 
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Figure  D-14:  GENERATE_KALMAN_OBS_SET  Logical  data  flow  diagram 
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m.  RF^KALMAN^PROC 
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2 
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1 
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1 

TIMEEXTI 
COVAF 
SINCE  LAS 

- 1 

L\POLATE 

OANCE 

T  UPDATE 

1 - 

:  P(t  +  At)  =  ®P(t)0^ +[QA}  j 

:  o.  ZERO  STATE  VECTOR 
I  ELEMENT 

j  XA(k)  =  0.0  k  =1,8 

!  p.  ZERO  STATE 

I  COVARIANCE 

j  PA(i,j)  =  0.0  i,j  =  l,8 

i  q.  SET  COVARIANCE 
j  DIAGONAL  TERMS 
PA(l,l)=POSX 
!  PA(3,3)=POSX 

j  PA(5,5)  =  POSX 

PA(7,7)  =  BCX 
!  PA(8,8)  =  PCX 

:  r.  ZERO  PROCESS  NOISE 

!  MATRIX 

!  Q(ij)  =  0.0  i,j  =  l,8 

I  s.  SET  PROCESS  NOISE 
!  DIAGONAL  TERMS 
j  QA(1,1)=PNX 

QA(3,3)  =  PNX 
!  QA(5,5)  =  PNX 

i  QA(7,7)  =  BCPNX 

j  QA(8,8)  =  FCPNX 

i  t  ZERO  OBSERVATION 
j  NOISE  MATRIX 

:  RA(12,12) 

I  u.  SET 

I  RA(1,1)=RNX 

!  RA(2,2)  =  RNX2 

i  PA(k,k)=RNX3 

:  k  =  3,12 


Figure  D-15:  RF_KALMAN_PROC  Logical  data  flow  diagram 
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BEGIN  OUTER 
UPDATE  LOOP 


END  OUTER  LOOP 


COMPUTE  KALMAN 
GAINMATRDC 
G(8, 12) 


:  G  =  PaHa^(HaPaHa^  +  R)' 


DO  I  =  1,  DIMUM 
DIMLIM  =  D  +  SCOUNT 


COMPUTE  RESIDUAL 
(I) 


RSL(I)  =YA(I)-YAEXP(I) 


BEGIN  INNER 


UPDATE  LOOP 


DOI=1,8DTA(I)  =  0.0 


DOJ=  LDIMLIM 


COMPUTE 

REHNEMENT  FILTER 
STATE  INCREMENTS 


:  DTA(I)  =DTA(I)-G(I,J)*RSL(J) 


END  INNER  LOOP 


DOI=L8 


UPDATE  RESTATE 
VECTOR 


XA(I)  =  XA(I)  +  DTA(I) 


GENERATE  ERROR 
TERMS  FOR  STATUS 
REPORT 


PERFORM 
OBSERVATION 
UPDATE  OF 
COVARIANCE 
MATRDC  PA 


ERRX  =  XA(1)  -  DXTRUE 
ERRY  =  XA  (3)  -  DYTRUE 
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ERRBC=  XA(7)  -  BCTRUE 
ERRFC=  XA(8)  -  FCTRUE 


Figure  D-16:  RF_KALMAN_PROC  Logical  data  flow  diagram  (cont.) 
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COMPUTE 
COVARIANCE 
DIAGONAL 
SQUARE  ROOTS 


SIGX  =:DSQRT(PA(1, 1)) 
SIGY  =DSQRT(PA(3,3)) 
SIGZ  =DSQRT(PA(5,5)) 
SIGBC  =  DSQRT  (PA  (7, 7)) 
SIGFC  =  DSQRT  (PA  (8,  8)) 


CHECK  FOR  STEADY 
STATE  ACHEIVED 


RESET 
RF_STATE  = 


METRIC  =  DSQRT  (PA  (1 , 1)  +  PA  (3,  3) 
+  PA(5, 5)) 


SET 

RF.STATUS 
INDICATOR  =  5 


TIME  (TC) 

RF_STATE 

RF_STATUS_INDICATOR 
X A  STATE  VECTOR  VALUES 
COVARIANCE  DIAGONAL  TERMS 
ERROR  TERMS 
SCOUNT 

SATVIS  (SCOUNT) 


Figure  D-17:  RF_KALMAN_PROC  Logical  data  flow  diagram  (cont) 
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TV.  OCP_INT_PROC 


c 


EXIT  K 


> 


CALL  PROCESS, 
MASTER, 
MESSAGE 

r 

CALL 

PROCESS,RAW, 
GPS  DATA 

r 

CALL 

CONVERT  NAV, 
DATA 

(MASTER  EST  DATA) 

1 

f 

CALL 

CONVERT  NAV, 
DATA 

(SELF  EST  DATA) 

DECOMPOSE  MASTER  MESSAGE  INTO 
NAV  DATA  AND  GPS  DATA 


ORDER  GPS  DATA 
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m 

MPRR 

■ 
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p 
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■ 
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Figure  D-18:  OCP_E<fT_PROC  Logical  data  flow  diagram 


Appendix  D  -  Flow  Diagrams 


Page  D20 


j 

OUTPUT 

I 

■ 

MNAVTOV 

i 

■ 

TMLAT 

■ 

TMLATR 

i 

■ 

TMLON 

i 

■ 

TMLONR 

■ 

TMALT 

i 

■ 

TMATTT? 

, .  J 

OUTPUT 

- • - 

i 

■ 

SNAVTOV 

■ 

TSLAT 

i 

■ 

TSLATR 

i 

■ 

TSLON 

■ 

TSLONR 

i 

■ 

TSALT 

] 

■ 

TSALTR 

■ 

BCTRUE 

i 

a 

FCTRUE 

j 

_ _ _  _ 

Figure  D-19:  OCP_INT_PROC  Logical  data  flow  diagram  (cont) 
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